doc: Add RFC documents

1 files changed, 1627 insertions, 0 deletions

diff --git a/doc/rfc/rfc3546.txt b/doc/rfc/rfc3546.txt
new file mode 100644
index 0000000..4392449
--- /dev/null
+++ b/doc/rfc/rfc3546.txt
@@ -0,0 +1,1627 @@
+
+
+
+
+
+
+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]
+