7Network Working Group S. Blake-Wilson
8Request for Comments: 4366 BCI
9Obsoletes: 3546 M. Nystrom
10Updates: 4346 RSA Security
11Category: Standards Track D. Hopwood
12 Independent Consultant
20 Transport Layer Security (TLS) Extensions
24 This document specifies an Internet standards track protocol for the
25 Internet community, and requests discussion and suggestions for
26 improvements. Please refer to the current edition of the "Internet
27 Official Protocol Standards" (STD 1) for the standardization state
28 and status of this protocol. Distribution of this memo is unlimited.
32 Copyright (C) The Internet Society (2006).
36 This document describes extensions that may be used to add
37 functionality to Transport Layer Security (TLS). It provides both
38 generic extension mechanisms for the TLS handshake client and server
39 hellos, and specific extensions using these generic mechanisms.
41 The extensions may be used by TLS clients and servers. The
42 extensions are backwards compatible: communication is possible
43 between TLS clients that support the extensions and TLS servers that
44 do not support the extensions, and vice versa.
58Blake-Wilson, et al. Standards Track [Page 1]
60RFC 4366 TLS Extensions April 2006
65 1. Introduction ....................................................3
66 1.1. Conventions Used in This Document ..........................5
67 2. General Extension Mechanisms ....................................5
68 2.1. Extended Client Hello ......................................5
69 2.2. Extended Server Hello ......................................6
70 2.3. Hello Extensions ...........................................6
71 2.4. Extensions to the Handshake Protocol .......................8
72 3. Specific Extensions .............................................8
73 3.1. Server Name Indication ....................................9
74 3.2. Maximum Fragment Length Negotiation ......................11
75 3.3. Client Certificate URLs ..................................12
76 3.4. Trusted CA Indication ....................................15
77 3.5. Truncated HMAC ............................................16
78 3.6. Certificate Status Request ................................17
79 4. Error Alerts ...................................................19
80 5. Procedure for Defining New Extensions ..........................20
81 6. Security Considerations ........................................21
82 6.1. Security of server_name ...................................22
83 6.2. Security of max_fragment_length ...........................22
84 6.3. Security of client_certificate_url ........................22
85 6.4. Security of trusted_ca_keys ...............................24
86 6.5. Security of truncated_hmac ................................24
87 6.6. Security of status_request ................................25
88 7. Internationalization Considerations ............................25
89 8. IANA Considerations ............................................25
90 9. Acknowledgements ...............................................27
91 10. Normative References ..........................................27
92 11. Informative References ........................................28
114Blake-Wilson, et al. Standards Track [Page 2]
116RFC 4366 TLS Extensions April 2006
121 This document describes extensions that may be used to add
122 functionality to Transport Layer Security (TLS). It provides both
123 generic extension mechanisms for the TLS handshake client and server
124 hellos, and specific extensions using these generic mechanisms.
126 TLS is now used in an increasing variety of operational environments,
127 many of which were not envisioned when the original design criteria
128 for TLS were determined. The extensions introduced in this document
129 are designed to enable TLS to operate as effectively as possible in
130 new environments such as wireless networks.
132 Wireless environments often suffer from a number of constraints not
133 commonly present in wired environments. These constraints may
134 include bandwidth limitations, computational power limitations,
135 memory limitations, and battery life limitations.
137 The extensions described here focus on extending the functionality
138 provided by the TLS protocol message formats. Other issues, such as
139 the addition of new cipher suites, are deferred.
141 Specifically, the extensions described in this document:
143 - Allow TLS clients to provide to the TLS server the name of the
144 server they are contacting. This functionality is desirable in
145 order to facilitate secure connections to servers that host
146 multiple 'virtual' servers at a single underlying network address.
148 - Allow TLS clients and servers to negotiate the maximum fragment
149 length to be sent. This functionality is desirable as a result of
150 memory constraints among some clients, and bandwidth constraints
151 among some access networks.
153 - Allow TLS clients and servers to negotiate the use of client
154 certificate URLs. This functionality is desirable in order to
155 conserve memory on constrained clients.
157 - Allow TLS clients to indicate to TLS servers which CA root keys
158 they possess. This functionality is desirable in order to prevent
159 multiple handshake failures involving TLS clients that are only
160 able to store a small number of CA root keys due to memory
163 - Allow TLS clients and servers to negotiate the use of truncated
164 MACs. This functionality is desirable in order to conserve
165 bandwidth in constrained access networks.
170Blake-Wilson, et al. Standards Track [Page 3]
172RFC 4366 TLS Extensions April 2006
175 - Allow TLS clients and servers to negotiate that the server sends
176 the client certificate status information (e.g., an Online
177 Certificate Status Protocol (OCSP) [OCSP] response) during a TLS
178 handshake. This functionality is desirable in order to avoid
179 sending a Certificate Revocation List (CRL) over a constrained
180 access network and therefore save bandwidth.
182 In order to support the extensions above, general extension
183 mechanisms for the client hello message and the server hello message
186 The extensions described in this document may be used by TLS clients
187 and servers. The extensions are designed to be backwards compatible,
188 meaning that TLS clients that support the extensions can talk to TLS
189 servers that do not support the extensions, and vice versa. The
190 document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis].
192 Backwards compatibility is primarily achieved via two considerations:
194 - Clients typically request the use of extensions via the extended
195 client hello message described in Section 2.1. TLS requires
196 servers to accept extended client hello messages, even if the
197 server does not "understand" the extension.
199 - For the specific extensions described here, no mandatory server
200 response is required when clients request extended functionality.
202 Essentially, backwards compatibility is achieved based on the TLS
203 requirement that servers that are not "extensions-aware" ignore data
204 added to client hellos that they do not recognize; for example, see
205 Section 7.4.1.2 of [TLS].
207 Note, however, that although backwards compatibility is supported,
208 some constrained clients may be forced to reject communications with
209 servers that do not support the extensions as a result of the limited
210 capabilities of such clients.
212 This document is a revision of the RFC3546 [RFC3546]. The only major
213 change concerns the definition of new extensions. New extensions can
214 now be defined via the IETF Consensus Process (rather than requiring
215 a standards track RFC). In addition, a few minor clarifications and
216 editorial improvements were made.
218 The remainder of this document is organized as follows. Section 2
219 describes general extension mechanisms for the client hello and
220 server hello handshake messages. Section 3 describes specific
221 extensions to TLS. Section 4 describes new error alerts for use with
226Blake-Wilson, et al. Standards Track [Page 4]
228RFC 4366 TLS Extensions April 2006
231 the TLS extensions. The final sections of the document address IPR,
232 security considerations, registration of the application/pkix-pkipath
233 MIME type, acknowledgements, and references.
2351.1. Conventions Used in This Document
237 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
238 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
239 document are to be interpreted as described in BCP 14, RFC 2119
2422. General Extension Mechanisms
244 This section presents general extension mechanisms for the TLS
245 handshake client hello and server hello messages.
247 These general extension mechanisms are necessary in order to enable
248 clients and servers to negotiate whether to use specific extensions,
249 and how to use specific extensions. The extension formats described
250 are based on [MAILINGLIST].
252 Section 2.1 specifies the extended client hello message format,
253 Section 2.2 specifies the extended server hello message format, and
254 Section 2.3 describes the actual extension format used with the
255 extended client and server hellos.
2572.1. Extended Client Hello
259 Clients MAY request extended functionality from servers by sending
260 the extended client hello message format in place of the client hello
261 message format. The extended client hello message format is:
264 ProtocolVersion client_version;
266 SessionID session_id;
267 CipherSuite cipher_suites<2..2^16-1>;
268 CompressionMethod compression_methods<1..2^8-1>;
269 Extension client_hello_extension_list<0..2^16-1>;
272 Here the new "client_hello_extension_list" field contains a list of
273 extensions. The actual "Extension" format is defined in Section 2.3.
275 In the event that a client requests additional functionality using
276 the extended client hello, and this functionality is not supplied by
277 the server, the client MAY abort the handshake.
282Blake-Wilson, et al. Standards Track [Page 5]
284RFC 4366 TLS Extensions April 2006
287 Note that [TLS], Section 7.4.1.2, allows additional information to be
288 added to the client hello message. Thus, the use of the extended
289 client hello defined above should not "break" existing TLS servers.
291 A server that supports the extensions mechanism MUST accept only
292 client hello messages in either the original or extended ClientHello
293 format and (as for all other messages) MUST check that the amount of
294 data in the message precisely matches one of these formats. If it
295 does not, then it MUST send a fatal "decode_error" alert. This
296 overrides the "Forward compatibility note" in [TLS].
2982.2. Extended Server Hello
300 The extended server hello message format MAY be sent in place of the
301 server hello message when the client has requested extended
302 functionality via the extended client hello message specified in
303 Section 2.1. The extended server hello message format is:
306 ProtocolVersion server_version;
308 SessionID session_id;
309 CipherSuite cipher_suite;
310 CompressionMethod compression_method;
311 Extension server_hello_extension_list<0..2^16-1>;
314 Here the new "server_hello_extension_list" field contains a list of
315 extensions. The actual "Extension" format is defined in Section 2.3.
317 Note that the extended server hello message is only sent in response
318 to an extended client hello message. This prevents the possibility
319 that the extended server hello message could "break" existing TLS
324 The extension format for extended client hellos and extended server
328 ExtensionType extension_type;
329 opaque extension_data<0..2^16-1>;
338Blake-Wilson, et al. Standards Track [Page 6]
340RFC 4366 TLS Extensions April 2006
345 - "extension_type" identifies the particular extension type.
347 - "extension_data" contains information specific to the particular
350 The extension types defined in this document are:
353 server_name(0), max_fragment_length(1),
354 client_certificate_url(2), trusted_ca_keys(3),
355 truncated_hmac(4), status_request(5), (65535)
358 The list of defined extension types is maintained by the IANA. The
359 current list can be found at:
360 http://www.iana.org/assignments/tls-extensiontype-values. See
361 Sections 5 and 8 for more information on how new values are added.
363 Note that for all extension types (including those defined in the
364 future), the extension type MUST NOT appear in the extended server
365 hello unless the same extension type appeared in the corresponding
366 client hello. Thus clients MUST abort the handshake if they receive
367 an extension type in the extended server hello that they did not
368 request in the associated (extended) client hello.
370 Nonetheless, "server-oriented" extensions may be provided in the
371 future within this framework. Such an extension (say, of type x)
372 would require the client to first send an extension of type x in the
373 (extended) client hello with empty extension_data to indicate that it
374 supports the extension type. In this case, the client is offering
375 the capability to understand the extension type, and the server is
376 taking the client up on its offer.
378 Also note that when multiple extensions of different types are
379 present in the extended client hello or the extended server hello,
380 the extensions may appear in any order. There MUST NOT be more than
381 one extension of the same type.
383 Finally, note that an extended client hello may be sent both when
384 starting a new session and when requesting session resumption.
385 Indeed, a client that requests resumption of a session does not in
386 general know whether the server will accept this request, and
387 therefore it SHOULD send an extended client hello if it would
388 normally do so for a new session. In general the specification of
389 each extension type must include a discussion of the effect of the
390 extension both during new sessions and during resumed sessions.
394Blake-Wilson, et al. Standards Track [Page 7]
396RFC 4366 TLS Extensions April 2006
3992.4. Extensions to the Handshake Protocol
401 This document suggests the use of two new handshake messages,
402 "CertificateURL" and "CertificateStatus". These messages are
403 described in Section 3.3 and Section 3.6, respectively. The new
404 handshake message structure therefore becomes:
407 hello_request(0), client_hello(1), server_hello(2),
408 certificate(11), server_key_exchange (12),
409 certificate_request(13), server_hello_done(14),
410 certificate_verify(15), client_key_exchange(16),
411 finished(20), certificate_url(21), certificate_status(22),
416 HandshakeType msg_type; /* handshake type */
417 uint24 length; /* bytes in message */
418 select (HandshakeType) {
419 case hello_request: HelloRequest;
420 case client_hello: ClientHello;
421 case server_hello: ServerHello;
422 case certificate: Certificate;
423 case server_key_exchange: ServerKeyExchange;
424 case certificate_request: CertificateRequest;
425 case server_hello_done: ServerHelloDone;
426 case certificate_verify: CertificateVerify;
427 case client_key_exchange: ClientKeyExchange;
428 case finished: Finished;
429 case certificate_url: CertificateURL;
430 case certificate_status: CertificateStatus;
4343. Specific Extensions
436 This section describes the specific TLS extensions specified in this
439 Note that any messages associated with these extensions that are sent
440 during the TLS handshake MUST be included in the hash calculations
441 involved in "Finished" messages.
443 Note also that all the extensions defined in this section are
444 relevant only when a session is initiated. When a client includes
445 one or more of the defined extension types in an extended client
446 hello while requesting session resumption:
450Blake-Wilson, et al. Standards Track [Page 8]
452RFC 4366 TLS Extensions April 2006
455 - If the resumption request is denied, the use of the extensions is
456 negotiated as normal.
458 - If, on the other hand, the older session is resumed, then the
459 server MUST ignore the extensions and send a server hello
460 containing none of the extension types. In this case, the
461 functionality of these extensions negotiated during the original
462 session initiation is applied to the resumed session.
464 Section 3.1 describes the extension of TLS to allow a client to
465 indicate which server it is contacting. Section 3.2 describes the
466 extension that provides maximum fragment length negotiation. Section
467 3.3 describes the extension that allows client certificate URLs.
468 Section 3.4 describes the extension that allows a client to indicate
469 which CA root keys it possesses. Section 3.5 describes the extension
470 that allows the use of truncated HMAC. Section 3.6 describes the
471 extension that supports integration of certificate status information
472 messages into TLS handshakes.
4743.1. Server Name Indication
476 TLS does not provide a mechanism for a client to tell a server the
477 name of the server it is contacting. It may be desirable for clients
478 to provide this information to facilitate secure connections to
479 servers that host multiple 'virtual' servers at a single underlying
482 In order to provide the server name, clients MAY include an extension
483 of type "server_name" in the (extended) client hello. The
484 "extension_data" field of this extension SHALL contain
485 "ServerNameList" where:
490 case host_name: HostName;
498 opaque HostName<1..2^16-1>;
501 ServerName server_name_list<1..2^16-1>
506Blake-Wilson, et al. Standards Track [Page 9]
508RFC 4366 TLS Extensions April 2006
511 Currently, the only server names supported are DNS hostnames;
512 however, this does not imply any dependency of TLS on DNS, and other
513 name types may be added in the future (by an RFC that updates this
514 document). TLS MAY treat provided server names as opaque data and
515 pass the names and types to the application.
517 "HostName" contains the fully qualified DNS hostname of the server,
518 as understood by the client. The hostname is represented as a byte
519 string using UTF-8 encoding [UTF8], without a trailing dot.
521 If the hostname labels contain only US-ASCII characters, then the
522 client MUST ensure that labels are separated only by the byte 0x2E,
523 representing the dot character U+002E (requirement 1 in Section 3.1
524 of [IDNA] notwithstanding). If the server needs to match the
525 HostName against names that contain non-US-ASCII characters, it MUST
526 perform the conversion operation described in Section 4 of [IDNA],
527 treating the HostName as a "query string" (i.e., the AllowUnassigned
528 flag MUST be set). Note that IDNA allows labels to be separated by
529 any of the Unicode characters U+002E, U+3002, U+FF0E, and U+FF61;
530 therefore, servers MUST accept any of these characters as a label
531 separator. If the server only needs to match the HostName against
532 names containing exclusively ASCII characters, it MUST compare ASCII
533 names case-insensitively.
537 It is RECOMMENDED that clients include an extension of type
538 "server_name" in the client hello whenever they locate a server by a
541 A server that receives a client hello containing the "server_name"
542 extension MAY use the information contained in the extension to guide
543 its selection of an appropriate certificate to return to the client,
544 and/or other aspects of security policy. In this event, the server
545 SHALL include an extension of type "server_name" in the (extended)
546 server hello. The "extension_data" field of this extension SHALL be
549 If the server understood the client hello extension but does not
550 recognize the server name, it SHOULD send an "unrecognized_name"
551 alert (which MAY be fatal).
553 If an application negotiates a server name using an application
554 protocol and then upgrades to TLS, and if a server_name extension is
555 sent, then the extension SHOULD contain the same name that was
556 negotiated in the application protocol. If the server_name is
557 established in the TLS session handshake, the client SHOULD NOT
558 attempt to request a different server name at the application layer.
562Blake-Wilson, et al. Standards Track [Page 10]
564RFC 4366 TLS Extensions April 2006
5673.2. Maximum Fragment Length Negotiation
569 Without this extension, TLS specifies a fixed maximum plaintext
570 fragment length of 2^14 bytes. It may be desirable for constrained
571 clients to negotiate a smaller maximum fragment length due to memory
572 limitations or bandwidth limitations.
574 In order to negotiate smaller maximum fragment lengths, clients MAY
575 include an extension of type "max_fragment_length" in the (extended)
576 client hello. The "extension_data" field of this extension SHALL
580 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255)
583 whose value is the desired maximum fragment length. The allowed
584 values for this field are: 2^9, 2^10, 2^11, and 2^12.
586 Servers that receive an extended client hello containing a
587 "max_fragment_length" extension MAY accept the requested maximum
588 fragment length by including an extension of type
589 "max_fragment_length" in the (extended) server hello. The
590 "extension_data" field of this extension SHALL contain a
591 "MaxFragmentLength" whose value is the same as the requested maximum
594 If a server receives a maximum fragment length negotiation request
595 for a value other than the allowed values, it MUST abort the
596 handshake with an "illegal_parameter" alert. Similarly, if a client
597 receives a maximum fragment length negotiation response that differs
598 from the length it requested, it MUST also abort the handshake with
599 an "illegal_parameter" alert.
601 Once a maximum fragment length other than 2^14 has been successfully
602 negotiated, the client and server MUST immediately begin fragmenting
603 messages (including handshake messages), to ensure that no fragment
604 larger than the negotiated length is sent. Note that TLS already
605 requires clients and servers to support fragmentation of handshake
608 The negotiated length applies for the duration of the session
609 including session resumptions.
611 The negotiated length limits the input that the record layer may
612 process without fragmentation (that is, the maximum value of
613 TLSPlaintext.length; see [TLS], Section 6.2.1). Note that the output
614 of the record layer may be larger. For example, if the negotiated
618Blake-Wilson, et al. Standards Track [Page 11]
620RFC 4366 TLS Extensions April 2006
623 length is 2^9=512, then for currently defined cipher suites (those
624 defined in [TLS], [KERB], and [AESSUITES]), and when null compression
625 is used, the record layer output can be at most 793 bytes: 5 bytes of
626 headers, 512 bytes of application data, 256 bytes of padding, and 20
627 bytes of MAC. This means that in this event a TLS record layer peer
628 receiving a TLS record layer message larger than 793 bytes may
629 discard the message and send a "record_overflow" alert, without
630 decrypting the message.
6323.3. Client Certificate URLs
634 Without this extension, TLS specifies that when client authentication
635 is performed, client certificates are sent by clients to servers
636 during the TLS handshake. It may be desirable for constrained
637 clients to send certificate URLs in place of certificates, so that
638 they do not need to store their certificates and can therefore save
641 In order to negotiate sending certificate URLs to a server, clients
642 MAY include an extension of type "client_certificate_url" in the
643 (extended) client hello. The "extension_data" field of this
644 extension SHALL be empty.
646 (Note that it is necessary to negotiate use of client certificate
647 URLs in order to avoid "breaking" existing TLS servers.)
649 Servers that receive an extended client hello containing a
650 "client_certificate_url" extension MAY indicate that they are willing
651 to accept certificate URLs by including an extension of type
652 "client_certificate_url" in the (extended) server hello. The
653 "extension_data" field of this extension SHALL be empty.
655 After negotiation of the use of client certificate URLs has been
656 successfully completed (by exchanging hellos including
657 "client_certificate_url" extensions), clients MAY send a
658 "CertificateURL" message in place of a "Certificate" message:
661 individual_certs(0), pkipath(1), (255)
674Blake-Wilson, et al. Standards Track [Page 12]
676RFC 4366 TLS Extensions April 2006
681 URLAndOptionalHash url_and_hash_list<1..2^16-1>;
685 opaque url<1..2^16-1>;
686 Boolean hash_present;
687 select (hash_present) {
688 case false: struct {};
691 } URLAndOptionalHash;
695 Here "url_and_hash_list" contains a sequence of URLs and optional
698 When X.509 certificates are used, there are two possibilities:
700 - If CertificateURL.type is "individual_certs", each URL refers to a
701 single DER-encoded X.509v3 certificate, with the URL for the
702 client's certificate first.
704 - If CertificateURL.type is "pkipath", the list contains a single
705 URL referring to a DER-encoded certificate chain, using the type
706 PkiPath described in Section 8.
708 When any other certificate format is used, the specification that
709 describes use of that format in TLS should define the encoding format
710 of certificates or certificate chains, and any constraint on their
713 The hash corresponding to each URL at the client's discretion either
714 is not present or is the SHA-1 hash of the certificate or certificate
715 chain (in the case of X.509 certificates, the DER-encoded certificate
716 or the DER-encoded PkiPath).
718 Note that when a list of URLs for X.509 certificates is used, the
719 ordering of URLs is the same as that used in the TLS Certificate
720 message (see [TLS], Section 7.4.2), but opposite to the order in
721 which certificates are encoded in PkiPath. In either case, the
722 self-signed root certificate MAY be omitted from the chain, under the
723 assumption that the server must already possess it in order to
730Blake-Wilson, et al. Standards Track [Page 13]
732RFC 4366 TLS Extensions April 2006
735 Servers receiving "CertificateURL" SHALL attempt to retrieve the
736 client's certificate chain from the URLs and then process the
737 certificate chain as usual. A cached copy of the content of any URL
738 in the chain MAY be used, provided that a SHA-1 hash is present for
739 that URL and it matches the hash of the cached copy.
741 Servers that support this extension MUST support the http: URL scheme
742 for certificate URLs, and MAY support other schemes. Use of other
743 schemes than "http", "https", or "ftp" may create unexpected
746 If the protocol used is HTTP, then the HTTP server can be configured
747 to use the Cache-Control and Expires directives described in [HTTP]
748 to specify whether and for how long certificates or certificate
749 chains should be cached.
751 The TLS server is not required to follow HTTP redirects when
752 retrieving the certificates or certificate chain. The URLs used in
753 this extension SHOULD therefore be chosen not to depend on such
756 If the protocol used to retrieve certificates or certificate chains
757 returns a MIME-formatted response (as HTTP does), then the following
758 MIME Content-Types SHALL be used: when a single X.509v3 certificate
759 is returned, the Content-Type is "application/pkix-cert" [PKIOP], and
760 when a chain of X.509v3 certificates is returned, the Content-Type is
761 "application/pkix-pkipath" (see Section 8).
763 If a SHA-1 hash is present for an URL, then the server MUST check
764 that the SHA-1 hash of the contents of the object retrieved from that
765 URL (after decoding any MIME Content-Transfer-Encoding) matches the
766 given hash. If any retrieved object does not have the correct SHA-1
767 hash, the server MUST abort the handshake with a
768 "bad_certificate_hash_value" alert.
770 Note that clients may choose to send either "Certificate" or
771 "CertificateURL" after successfully negotiating the option to send
772 certificate URLs. The option to send a certificate is included to
773 provide flexibility to clients possessing multiple certificates.
775 If a server encounters an unreasonable delay in obtaining
776 certificates in a given CertificateURL, it SHOULD time out and signal
777 a "certificate_unobtainable" error alert.
786Blake-Wilson, et al. Standards Track [Page 14]
788RFC 4366 TLS Extensions April 2006
7913.4. Trusted CA Indication
793 Constrained clients that, due to memory limitations, possess only a
794 small number of CA root keys may wish to indicate to servers which
795 root keys they possess, in order to avoid repeated handshake
798 In order to indicate which CA root keys they possess, clients MAY
799 include an extension of type "trusted_ca_keys" in the (extended)
800 client hello. The "extension_data" field of this extension SHALL
801 contain "TrustedAuthorities" where:
804 TrustedAuthority trusted_authorities_list<0..2^16-1>;
805 } TrustedAuthorities;
808 IdentifierType identifier_type;
809 select (identifier_type) {
810 case pre_agreed: struct {};
811 case key_sha1_hash: SHA1Hash;
812 case x509_name: DistinguishedName;
813 case cert_sha1_hash: SHA1Hash;
818 pre_agreed(0), key_sha1_hash(1), x509_name(2),
819 cert_sha1_hash(3), (255)
822 opaque DistinguishedName<1..2^16-1>;
824 Here "TrustedAuthorities" provides a list of CA root key identifiers
825 that the client possesses. Each CA root key is identified via
828 - "pre_agreed": no CA root key identity supplied.
830 - "key_sha1_hash": contains the SHA-1 hash of the CA root key. For
831 Digital Signature Algorithm (DSA) and Elliptic Curve Digital
832 Signature Algorithm (ECDSA) keys, this is the hash of the
833 "subjectPublicKey" value. For RSA keys, the hash is of the big-
834 endian byte string representation of the modulus without any
835 initial 0-valued bytes. (This copies the key hash formats
836 deployed in other environments.)
842Blake-Wilson, et al. Standards Track [Page 15]
844RFC 4366 TLS Extensions April 2006
847 - "x509_name": contains the DER-encoded X.509 DistinguishedName of
850 - "cert_sha1_hash": contains the SHA-1 hash of a DER-encoded
851 Certificate containing the CA root key.
853 Note that clients may include none, some, or all of the CA root keys
854 they possess in this extension.
856 Note also that it is possible that a key hash or a Distinguished Name
857 alone may not uniquely identify a certificate issuer (for example, if
858 a particular CA has multiple key pairs). However, here we assume
859 this is the case following the use of Distinguished Names to identify
860 certificate issuers in TLS.
862 The option to include no CA root keys is included to allow the client
863 to indicate possession of some pre-defined set of CA root keys.
865 Servers that receive a client hello containing the "trusted_ca_keys"
866 extension MAY use the information contained in the extension to guide
867 their selection of an appropriate certificate chain to return to the
868 client. In this event, the server SHALL include an extension of type
869 "trusted_ca_keys" in the (extended) server hello. The
870 "extension_data" field of this extension SHALL be empty.
874 Currently defined TLS cipher suites use the MAC construction HMAC
875 with either MD5 or SHA-1 [HMAC] to authenticate record layer
876 communications. In TLS, the entire output of the hash function is
877 used as the MAC tag. However, it may be desirable in constrained
878 environments to save bandwidth by truncating the output of the hash
879 function to 80 bits when forming MAC tags.
881 In order to negotiate the use of 80-bit truncated HMAC, clients MAY
882 include an extension of type "truncated_hmac" in the extended client
883 hello. The "extension_data" field of this extension SHALL be empty.
885 Servers that receive an extended hello containing a "truncated_hmac"
886 extension MAY agree to use a truncated HMAC by including an extension
887 of type "truncated_hmac", with empty "extension_data", in the
888 extended server hello.
890 Note that if new cipher suites are added that do not use HMAC, and
891 the session negotiates one of these cipher suites, this extension
892 will have no effect. It is strongly recommended that any new cipher
898Blake-Wilson, et al. Standards Track [Page 16]
900RFC 4366 TLS Extensions April 2006
903 suites using other MACs consider the MAC size an integral part of the
904 cipher suite definition, taking into account both security and
905 bandwidth considerations.
907 If HMAC truncation has been successfully negotiated during a TLS
908 handshake, and the negotiated cipher suite uses HMAC, both the client
909 and the server pass this fact to the TLS record layer along with the
910 other negotiated security parameters. Subsequently during the
911 session, clients and servers MUST use truncated HMACs, calculated as
912 specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and
913 only the first 10 bytes of the HMAC output are transmitted and
914 checked. Note that this extension does not affect the calculation of
915 the pseudo-random function (PRF) as part of handshaking or key
918 The negotiated HMAC truncation size applies for the duration of the
919 session including session resumptions.
9213.6. Certificate Status Request
923 Constrained clients may wish to use a certificate-status protocol
924 such as OCSP [OCSP] to check the validity of server certificates, in
925 order to avoid transmission of CRLs and therefore save bandwidth on
926 constrained networks. This extension allows for such information to
927 be sent in the TLS handshake, saving roundtrips and resources.
929 In order to indicate their desire to receive certificate status
930 information, clients MAY include an extension of type
931 "status_request" in the (extended) client hello. The
932 "extension_data" field of this extension SHALL contain
933 "CertificateStatusRequest" where:
936 CertificateStatusType status_type;
937 select (status_type) {
938 case ocsp: OCSPStatusRequest;
940 } CertificateStatusRequest;
942 enum { ocsp(1), (255) } CertificateStatusType;
945 ResponderID responder_id_list<0..2^16-1>;
946 Extensions request_extensions;
949 opaque ResponderID<1..2^16-1>;
950 opaque Extensions<0..2^16-1>;
954Blake-Wilson, et al. Standards Track [Page 17]
956RFC 4366 TLS Extensions April 2006
959 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP
960 responders that the client trusts. A zero-length "responder_id_list"
961 sequence has the special meaning that the responders are implicitly
962 known to the server, e.g., by prior arrangement. "Extensions" is a
963 DER encoding of OCSP request extensions.
965 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as
966 defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero-
967 length "request_extensions" value means that there are no extensions
968 (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for
969 the "Extensions" type).
971 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is
972 unclear about its encoding; for clarification, the nonce MUST be a
973 DER-encoded OCTET STRING, which is encapsulated as another OCTET
974 STRING (note that implementations based on an existing OCSP client
975 will need to be checked for conformance to this requirement).
977 Servers that receive a client hello containing the "status_request"
978 extension MAY return a suitable certificate status response to the
979 client along with their certificate. If OCSP is requested, they
980 SHOULD use the information contained in the extension when selecting
981 an OCSP responder and SHOULD include request_extensions in the OCSP
984 Servers return a certificate response along with their certificate by
985 sending a "CertificateStatus" message immediately after the
986 "Certificate" message (and before any "ServerKeyExchange" or
987 "CertificateRequest" messages). If a server returns a
989 "CertificateStatus" message, then the server MUST have included an
990 extension of type "status_request" with empty "extension_data" in the
991 extended server hello.
994 CertificateStatusType status_type;
995 select (status_type) {
996 case ocsp: OCSPResponse;
1000 opaque OCSPResponse<1..2^24-1>;
1002 An "ocsp_response" contains a complete, DER-encoded OCSP response
1003 (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that
1004 only one OCSP response may be sent.
1010Blake-Wilson, et al. Standards Track [Page 18]
1012RFC 4366 TLS Extensions April 2006
1015 The "CertificateStatus" message is conveyed using the handshake
1016 message type "certificate_status".
1018 Note that a server MAY also choose not to send a "CertificateStatus"
1019 message, even if it receives a "status_request" extension in the
1020 client hello message.
1022 Note in addition that servers MUST NOT send the "CertificateStatus"
1023 message unless it received a "status_request" extension in the client
1026 Clients requesting an OCSP response and receiving an OCSP response in
1027 a "CertificateStatus" message MUST check the OCSP response and abort
1028 the handshake if the response is not satisfactory.
1032 This section defines new error alerts for use with the TLS extensions
1033 defined in this document.
1035 The following new error alerts are defined. To avoid "breaking"
1036 existing clients and servers, these alerts MUST NOT be sent unless
1037 the sending party has received an extended hello message from the
1038 party they are communicating with.
1040 - "unsupported_extension": this alert is sent by clients that
1041 receive an extended server hello containing an extension that they
1042 did not put in the corresponding client hello (see Section 2.3).
1043 This message is always fatal.
1045 - "unrecognized_name": this alert is sent by servers that receive a
1046 server_name extension request, but do not recognize the server
1047 name. This message MAY be fatal.
1049 - "certificate_unobtainable": this alert is sent by servers who are
1050 unable to retrieve a certificate chain from the URL supplied by
1051 the client (see Section 3.3). This message MAY be fatal; for
1052 example, if client authentication is required by the server for
1053 the handshake to continue and the server is unable to retrieve the
1054 certificate chain, it may send a fatal alert.
1056 - "bad_certificate_status_response": this alert is sent by clients
1057 that receive an invalid certificate status response (see Section
1058 3.6). This message is always fatal.
1060 - "bad_certificate_hash_value": this alert is sent by servers when a
1061 certificate hash does not match a client-provided
1062 certificate_hash. This message is always fatal.
1066Blake-Wilson, et al. Standards Track [Page 19]
1068RFC 4366 TLS Extensions April 2006
1071 These error alerts are conveyed using the following syntax:
1075 unexpected_message(10),
1077 decryption_failed(21),
1078 record_overflow(22),
1079 decompression_failure(30),
1080 handshake_failure(40),
1081 /* 41 is not defined, for historical reasons */
1082 bad_certificate(42),
1083 unsupported_certificate(43),
1084 certificate_revoked(44),
1085 certificate_expired(45),
1086 certificate_unknown(46),
1087 illegal_parameter(47),
1092 export_restriction(60),
1093 protocol_version(70),
1094 insufficient_security(71),
1097 no_renegotiation(100),
1098 unsupported_extension(110), /* new */
1099 certificate_unobtainable(111), /* new */
1100 unrecognized_name(112), /* new */
1101 bad_certificate_status_response(113), /* new */
1102 bad_certificate_hash_value(114), /* new */
11065. Procedure for Defining New Extensions
1108 The list of extension types, as defined in Section 2.3, is maintained
1109 by the Internet Assigned Numbers Authority (IANA). Thus, an
1110 application needs to be made to the IANA in order to obtain a new
1111 extension type value. Since there are subtle (and not-so-subtle)
1112 interactions that may occur in this protocol between new features and
1113 existing features that may result in a significant reduction in
1114 overall security, new values SHALL be defined only through the IETF
1115 Consensus process specified in [IANA].
1117 (This means that new assignments can be made only via RFCs approved
1122Blake-Wilson, et al. Standards Track [Page 20]
1124RFC 4366 TLS Extensions April 2006
1127 The following considerations should be taken into account when
1128 designing new extensions:
1130 - All of the extensions defined in this document follow the
1131 convention that for each extension that a client requests and that
1132 the server understands, the server replies with an extension of
1135 - Some cases where a server does not agree to an extension are error
1136 conditions, and some simply a refusal to support a particular
1137 feature. In general, error alerts should be used for the former,
1138 and a field in the server extension response for the latter.
1140 - Extensions should as far as possible be designed to prevent any
1141 attack that forces use (or non-use) of a particular feature by
1142 manipulation of handshake messages. This principle should be
1143 followed regardless of whether the feature is believed to cause a
1146 Often the fact that the extension fields are included in the
1147 inputs to the Finished message hashes will be sufficient, but
1148 extreme care is needed when the extension changes the meaning of
1149 messages sent in the handshake phase. Designers and implementors
1150 should be aware of the fact that until the handshake has been
1151 authenticated, active attackers can modify messages and insert,
1152 remove, or replace extensions.
1154 - It would be technically possible to use extensions to change major
1155 aspects of the design of TLS; for example, the design of cipher
1156 suite negotiation. This is not recommended; it would be more
1157 appropriate to define a new version of TLS, particularly since the
1158 TLS handshake algorithms have specific protection against version
1159 rollback attacks based on the version number. The possibility of
1160 version rollback should be a significant consideration in any
1161 major design change.
11636. Security Considerations
1165 Security considerations for the extension mechanism in general and
1166 for the design of new extensions are described in the previous
1167 section. A security analysis of each of the extensions defined in
1168 this document is given below.
1170 In general, implementers should continue to monitor the state of the
1171 art and address any weaknesses identified.
1173 Additional security considerations are described in the TLS 1.0 RFC
1174 [TLS] and the TLS 1.1 RFC [TLSbis].
1178Blake-Wilson, et al. Standards Track [Page 21]
1180RFC 4366 TLS Extensions April 2006
11836.1. Security of server_name
1185 If a single server hosts several domains, then clearly it is
1186 necessary for the owners of each domain to ensure that this satisfies
1187 their security needs. Apart from this, server_name does not appear
1188 to introduce significant security issues.
1190 Implementations MUST ensure that a buffer overflow does not occur,
1191 whatever the values of the length fields in server_name.
1193 Although this document specifies an encoding for internationalized
1194 hostnames in the server_name extension, it does not address any
1195 security issues associated with the use of internationalized
1196 hostnames in TLS (in particular, the consequences of "spoofed" names
1197 that are indistinguishable from another name when displayed or
1198 printed). It is recommended that server certificates not be issued
1199 for internationalized hostnames unless procedures are in place to
1200 mitigate the risk of spoofed hostnames.
12026.2. Security of max_fragment_length
1204 The maximum fragment length takes effect immediately, including for
1205 handshake messages. However, that does not introduce any security
1206 complications that are not already present in TLS, since TLS requires
1207 implementations to be able to handle fragmented handshake messages.
1209 Note that as described in Section 3.2, once a non-null cipher suite
1210 has been activated, the effective maximum fragment length depends on
1211 the cipher suite and compression method, as well as on the negotiated
1212 max_fragment_length. This must be taken into account when sizing
1213 buffers, and checking for buffer overflow.
12156.3. Security of client_certificate_url
1217 There are two major issues with this extension.
1219 The first major issue is whether or not clients should include
1220 certificate hashes when they send certificate URLs.
1222 When client authentication is used *without* the
1223 client_certificate_url extension, the client certificate chain is
1224 covered by the Finished message hashes. The purpose of including
1225 hashes and checking them against the retrieved certificate chain is
1226 to ensure that the same property holds when this extension is used,
1227 i.e., that all of the information in the certificate chain retrieved
1228 by the server is as the client intended.
1234Blake-Wilson, et al. Standards Track [Page 22]
1236RFC 4366 TLS Extensions April 2006
1239 On the other hand, omitting certificate hashes enables functionality
1240 that is desirable in some circumstances; for example, clients can be
1241 issued daily certificates that are stored at a fixed URL and need not
1242 be provided to the client. Clients that choose to omit certificate
1243 hashes should be aware of the possibility of an attack in which the
1244 attacker obtains a valid certificate on the client's key that is
1245 different from the certificate the client intended to provide.
1246 Although TLS uses both MD5 and SHA-1 hashes in several other places,
1247 this was not believed to be necessary here. The property required of
1248 SHA-1 is second pre-image resistance.
1250 The second major issue is that support for client_certificate_url
1251 involves the server's acting as a client in another URL protocol.
1252 The server therefore becomes subject to many of the same security
1253 concerns that clients of the URL scheme are subject to, with the
1254 added concern that the client can attempt to prompt the server to
1255 connect to some (possibly weird-looking) URL.
1257 In general, this issue means that an attacker might use the server to
1258 indirectly attack another host that is vulnerable to some security
1259 flaw. It also introduces the possibility of denial of service
1260 attacks in which an attacker makes many connections to the server,
1261 each of which results in the server's attempting a connection to the
1262 target of the attack.
1264 Note that the server may be behind a firewall or otherwise able to
1265 access hosts that would not be directly accessible from the public
1266 Internet. This could exacerbate the potential security and denial of
1267 service problems described above, as well as allow the existence of
1268 internal hosts to be confirmed when they would otherwise be hidden.
1270 The detailed security concerns involved will depend on the URL
1271 schemes supported by the server. In the case of HTTP, the concerns
1272 are similar to those that apply to a publicly accessible HTTP proxy
1273 server. In the case of HTTPS, loops and deadlocks may be created,
1274 and this should be addressed. In the case of FTP, attacks arise that
1275 are similar to FTP bounce attacks.
1277 As a result of this issue, it is RECOMMENDED that the
1278 client_certificate_url extension should have to be specifically
1279 enabled by a server administrator, rather than be enabled by default.
1280 It is also RECOMMENDED that URI protocols be enabled by the
1281 administrator individually, and only a minimal set of protocols be
1282 enabled. Unusual protocols that offer limited security or whose
1283 security is not well-understood SHOULD be avoided.
1290Blake-Wilson, et al. Standards Track [Page 23]
1292RFC 4366 TLS Extensions April 2006
1295 As discussed in [URI], URLs that specify ports other than the default
1296 may cause problems, as may very long URLs (which are more likely to
1297 be useful in exploiting buffer overflow bugs).
1299 Also note that HTTP caching proxies are common on the Internet, and
1300 some proxies do not check for the latest version of an object
1301 correctly. If a request using HTTP (or another caching protocol)
1302 goes through a misconfigured or otherwise broken proxy, the proxy may
1303 return an out-of-date response.
13056.4. Security of trusted_ca_keys
1307 It is possible that which CA root keys a client possesses could be
1308 regarded as confidential information. As a result, the CA root key
1309 indication extension should be used with care.
1311 The use of the SHA-1 certificate hash alternative ensures that each
1312 certificate is specified unambiguously. As for the previous
1313 extension, it was not believed necessary to use both MD5 and SHA-1
13166.5. Security of truncated_hmac
1318 It is possible that truncated MACs are weaker than "un-truncated"
1319 MACs. However, no significant weaknesses are currently known or
1320 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits.
1322 Note that the output length of a MAC need not be as long as the
1323 length of a symmetric cipher key, since forging of MAC values cannot
1324 be done off-line: in TLS, a single failed MAC guess will cause the
1325 immediate termination of the TLS session.
1327 Since the MAC algorithm only takes effect after all handshake
1328 messages that affect extension parameters have been authenticated by
1329 the hashes in the Finished messages, it is not possible for an active
1330 attacker to force negotiation of the truncated HMAC extension where
1331 it would not otherwise be used (to the extent that the handshake
1332 authentication is secure). Therefore, in the event that any security
1333 problem were found with truncated HMAC in the future, if either the
1334 client or the server for a given session were updated to take the
1335 problem into account, it would be able to veto use of this extension.
1346Blake-Wilson, et al. Standards Track [Page 24]
1348RFC 4366 TLS Extensions April 2006
13516.6. Security of status_request
1353 If a client requests an OCSP response, it must take into account that
1354 an attacker's server using a compromised key could (and probably
1355 would) pretend not to support the extension. In this case, a client
1356 that requires OCSP validation of certificates SHOULD either contact
1357 the OCSP server directly or abort the handshake.
1359 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may
1360 improve security against attacks that attempt to replay OCSP
1361 responses; see Section 4.4.1 of [OCSP] for further details.
13637. Internationalization Considerations
1365 None of the extensions defined here directly use strings subject to
1366 localization. Domain Name System (DNS) hostnames are encoded using
1367 UTF-8. If future extensions use text strings, then
1368 internationalization should be considered in their design.
13708. IANA Considerations
1372 Sections 2.3 and 5 describe a registry of ExtensionType values to be
1373 maintained by the IANA. ExtensionType values are to be assigned via
1374 IETF Consensus as defined in RFC 2434 [IANA]. The initial registry
1375 corresponds to the definition of "ExtensionType" in Section 2.3.
1377 The MIME type "application/pkix-pkipath" has been registered by the
1378 IANA with the following template:
1380 To: ietf-types@iana.org
1381 Subject: Registration of MIME media type application/pkix-pkipath
1383 MIME media type name: application
1384 MIME subtype name: pkix-pkipath
1385 Required parameters: none
1387 Optional parameters: version (default value is "1")
1389 Encoding considerations:
1390 This MIME type is a DER encoding of the ASN.1 type PkiPath,
1392 PkiPath ::= SEQUENCE OF Certificate
1393 PkiPath is used to represent a certification path. Within the
1394 sequence, the order of certificates is such that the subject of
1395 the first certificate is the issuer of the second certificate,
1402Blake-Wilson, et al. Standards Track [Page 25]
1404RFC 4366 TLS Extensions April 2006
1407 This is identical to the definition published in [X509-4th-TC1];
1408 note that it is different from that in [X509-4th].
1410 All Certificates MUST conform to [PKIX]. (This should be
1411 interpreted as a requirement to encode only PKIX-conformant
1412 certificates using this type. It does not necessarily require
1413 that all certificates that are not strictly PKIX-conformant must
1414 be rejected by relying parties, although the security consequences
1415 of accepting any such certificates should be considered
1418 DER (as opposed to BER) encoding MUST be used. If this type is
1419 sent over a 7-bit transport, base64 encoding SHOULD be used.
1421 Security considerations:
1422 The security considerations of [X509-4th] and [PKIX] (or any
1423 updates to them) apply, as well as those of any protocol that uses
1424 this type (e.g., TLS).
1426 Note that this type only specifies a certificate chain that can be
1427 assessed for validity according to the relying party's existing
1428 configuration of trusted CAs; it is not intended to be used to
1429 specify any change to that configuration.
1431 Interoperability considerations:
1432 No specific interoperability problems are known with this type,
1433 but for recommendations relating to X.509 certificates in general,
1436 Published specification: RFC 4366 (this memo), and [PKIX].
1438 Applications which use this media type: TLS. It may also be used by
1439 other protocols, or for general interchange of PKIX certificate
1442 Additional information:
1443 Magic number(s): DER-encoded ASN.1 can be easily recognized.
1444 Further parsing is required to distinguish it from other ASN.1
1446 File extension(s): .pkipath
1447 Macintosh File Type Code(s): not specified
1449 Person & email address to contact for further information:
1450 Magnus Nystrom <magnus@rsasecurity.com>
1452 Intended usage: COMMON
1458Blake-Wilson, et al. Standards Track [Page 26]
1460RFC 4366 TLS Extensions April 2006
1464 IESG <iesg@ietf.org>
1468 The authors wish to thank the TLS Working Group and the WAP Security
1469 Group. This document is based on discussion within these groups.
147110. Normative References
1473 [HMAC] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
1474 Keyed-Hashing for Message Authentication", RFC 2104,
1477 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
1478 Masinter, L., Leach, P., and T. Berners-Lee,
1479 "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616,
1482 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing
1483 an IANA Considerations Section in RFCs", BCP 26, RFC
1486 [IDNA] Faltstrom, P., Hoffman, P., and A. Costello,
1487 "Internationalizing Domain Names in Applications
1488 (IDNA)", RFC 3490, March 2003.
1490 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
1491 Requirement Levels", BCP 14, RFC 2119, March 1997.
1493 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and
1494 C. Adams, "X.509 Internet Public Key Infrastructure
1495 Online Certificate Status Protocol - OCSP", RFC 2560,
1498 [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
1499 Infrastructure Operational Protocols: FTP and HTTP",
1502 [PKIX] Housley, R., Polk, W., Ford, W., and D. Solo,
1503 "Internet X.509 Public Key Infrastructure Certificate
1504 and Certificate Revocation List (CRL) Profile", RFC
1507 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version
1508 1.0", RFC 2246, January 1999.
1514Blake-Wilson, et al. Standards Track [Page 27]
1516RFC 4366 TLS Extensions April 2006
1519 [TLSbis] Dierks, T. and E. Rescorla, "The Transport Layer
1520 Security (TLS) Protocol Version 1.1", RFC 4346, April
1523 [URI] Berners-Lee, T., Fielding, R., and L. Masinter,
1524 "Uniform Resource Identifier (URI): Generic Syntax",
1525 STD 66, RFC 3986, January 2005.
1527 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO
1528 10646", STD 63, RFC 3629, November 2003.
1530 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC
1531 9594-8:2001, "Information Systems - Open Systems
1532 Interconnection - The Directory: Public key and
1533 attribute certificate frameworks."
1535 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) |
1536 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum
1537 1 to ISO/IEC 9594:8:2001.
153911. Informative References
1541 [AESSUITES] Chown, P., "Advanced Encryption Standard (AES)
1542 Ciphersuites for Transport Layer Security (TLS)", RFC
1545 [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
1546 Suites to Transport Layer Security (TLS)", RFC 2712,
1549 [MAILINGLIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General
1550 ClientHello extension mechanism and virtual hosting,"
1551 ietf-tls mailing list posting, August 14, 2000.
1553 [RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen,
1554 J., and T. Wright, "Transport Layer Security (TLS)
1555 Extensions", RFC 3546, June 2003.
1570Blake-Wilson, et al. Standards Track [Page 28]
1572RFC 4366 TLS Extensions April 2006
1580 EMail: sblakewilson@bcisse.com
1586 EMail: magnus@rsasecurity.com
1590 Independent Consultant
1592 EMail: david.hopwood@blueyonder.co.uk
1598 EMail: janm@transactionware.com
1604 EMail: timothy.wright@vodafone.com
1626Blake-Wilson, et al. Standards Track [Page 29]
1628RFC 4366 TLS Extensions April 2006
1631Full Copyright Statement
1633 Copyright (C) The Internet Society (2006).
1635 This document is subject to the rights, licenses and restrictions
1636 contained in BCP 78, and except as set forth therein, the authors
1637 retain all their rights.
1639 This document and the information contained herein are provided on an
1640 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
1641 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
1642 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
1643 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
1644 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
1645 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
1647Intellectual Property
1649 The IETF takes no position regarding the validity or scope of any
1650 Intellectual Property Rights or other rights that might be claimed to
1651 pertain to the implementation or use of the technology described in
1652 this document or the extent to which any license under such rights
1653 might or might not be available; nor does it represent that it has
1654 made any independent effort to identify any such rights. Information
1655 on the procedures with respect to rights in RFC documents can be
1656 found in BCP 78 and BCP 79.
1658 Copies of IPR disclosures made to the IETF Secretariat and any
1659 assurances of licenses to be made available, or the result of an
1660 attempt made to obtain a general license or permission for the use of
1661 such proprietary rights by implementers or users of this
1662 specification can be obtained from the IETF on-line IPR repository at
1663 http://www.ietf.org/ipr.
1665 The IETF invites any interested party to bring to its attention any
1666 copyrights, patents or patent applications, or other proprietary
1667 rights that may cover technology that may be required to implement
1668 this standard. Please address the information to the IETF at
1673 Funding for the RFC Editor function is provided by the IETF
1674 Administrative Support Activity (IASA).
1682Blake-Wilson, et al. Standards Track [Page 30]