| < draft-ietf-tls-rfc3546bis-01.txt | draft-ietf-tls-rfc3546bis-02.txt > | |||
|---|---|---|---|---|
| TLS Working Group S. Blake-Wilson | TLS Working Group S. Blake-Wilson | |||
| Internet-Draft BCI | Internet-Draft BCI | |||
| Obsoletes: 3546 (if approved) M. Nystrom | Obsoletes: 3546 (if approved) M. Nystrom | |||
| Updates: 2246 RSA Security | Updates: 2246 & [TBD for TLS1.1 RFC] RSA Security | |||
| Category: Standards Track D. Hopwood | Category: Standards Track D. Hopwood | |||
| Expires: November 2005 Independent Consultant | Expires: March 2006 Independent Consultant | |||
| J. Mikkelsen | J. Mikkelsen | |||
| Transactionware | Transactionware | |||
| T. Wright | T. Wright | |||
| Vodafone | Vodafone | |||
| May 2005 | September 2005 | |||
| Transport Layer Security (TLS) Extensions | Transport Layer Security (TLS) Extensions | |||
| <draft-ietf-tls-rfc3546bis-01.txt> | <draft-ietf-tls-rfc3546bis-02.txt> | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft and is subject to all provisions | ||||
| of section 3 of RFC 3667. | ||||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| skipping to change at page 1, line 44 ¶ | skipping to change at page 1, line 41 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at http:// | The list of current Internet-Drafts can be accessed at http:// | |||
| www.ietf.org/ietf/1id-abstracts.txt. | www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire in November 2005. | This Internet-Draft will expire in March 2006. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The Internet Society (2005). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
| Abstract | Abstract | |||
| This document describes extensions that may be used to add | This document describes extensions that may be used to add | |||
| functionality to Transport Layer Security (TLS). It provides both | functionality to Transport Layer Security (TLS). It provides both | |||
| generic extension mechanisms for the TLS handshake client and server | generic extension mechanisms for the TLS handshake client and server | |||
| hellos, and specific extensions using these generic mechanisms. | hellos, and specific extensions using these generic mechanisms. | |||
| The extensions may be used by TLS clients and servers. The | The extensions may be used by TLS clients and servers. The | |||
| extensions are backwards compatible - communication is possible | extensions are backwards compatible - communication is possible | |||
| between TLS 1.0 clients that support the extensions and TLS 1.0 | between TLS clients that support the extensions and TLS | |||
| servers that do not support the extensions, and vice versa. | servers that do not support the extensions, and vice versa. | |||
| Conventions used in this Document | Conventions used in this Document | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
| document are to be interpreted as described in BCP 14, RFC 2119 | document are to be interpreted as described in BCP 14, RFC 2119 | |||
| [KEYWORDS]. | [KEYWORDS]. | |||
| Table of Contents | Table of Contents | |||
| skipping to change at page 3, line 51 ¶ | skipping to change at page 3, line 51 ¶ | |||
| the client certificate status information (e.g., an Online | the client certificate status information (e.g., an Online | |||
| Certificate Status Protocol (OCSP) [OCSP] response) during a TLS | Certificate Status Protocol (OCSP) [OCSP] response) during a TLS | |||
| handshake. This functionality is desirable in order to avoid | handshake. This functionality is desirable in order to avoid | |||
| sending a Certificate Revocation List (CRL) over a constrained | sending a Certificate Revocation List (CRL) over a constrained | |||
| access network and therefore save bandwidth. | access network and therefore save bandwidth. | |||
| In order to support the extensions above, general extension | In order to support the extensions above, general extension | |||
| mechanisms for the client hello message and the server hello message | mechanisms for the client hello message and the server hello message | |||
| are introduced. | are introduced. | |||
| The extensions described in this document may be used by TLS 1.0 | The extensions described in this document may be used by TLS clients | |||
| clients and TLS 1.0 servers. The extensions are designed to be | and servers. The extensions are designed to be backwards compatible | |||
| backwards compatible - meaning that TLS 1.0 clients that support the | - meaning that TLS clients that support the extensions can talk to | |||
| extensions can talk to TLS 1.0 servers that do not support the | TLS servers that do not support the extensions, and vice versa. The | |||
| extensions, and vice versa. | document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis]. | |||
| Backwards compatibility is primarily achieved via two considerations: | Backwards compatibility is primarily achieved via two considerations: | |||
| - Clients typically request the use of extensions via the extended | - Clients typically request the use of extensions via the extended | |||
| client hello message described in Section 2.1. TLS 1.0 [TLS] | client hello message described in Section 2.1. TLS requires | |||
| requires servers to accept extended client hello messages, even if | servers to accept extended client hello messages, even if the | |||
| the server does not "understand" the extension. | server does not "understand" the extension. | |||
| - For the specific extensions described here, no mandatory server | - For the specific extensions described here, no mandatory server | |||
| response is required when clients request extended functionality. | response is required when clients request extended functionality. | |||
| Essentially backwards compatibility is achieved based on the TLS | ||||
| requirement that servers that are not "extensions-aware" ignore | ||||
| data added to client hellos that they do not recognize -- see, for | ||||
| example, Section 7.4.1.2 of [TLS]. | ||||
| Note however, that although backwards compatibility is supported, | Note however, that although backwards compatibility is supported, | |||
| some constrained clients may be forced to reject communications with | some constrained clients may be forced to reject communications with | |||
| servers that do not support the extensions as a result of the limited | servers that do not support the extensions as a result of the limited | |||
| capabilities of such clients. | capabilities of such clients. | |||
| This document is a revision of the RFC3546 [RFC3546]. The only | This document is a revision of the RFC3546 [RFC3546]. The only | |||
| major change concerns the definition of new extensions. New | major change concerns the definition of new extensions. New | |||
| extensions can now be defined via the IETF Consensus Process (rather | extensions can now be defined via the IETF Consensus Process (rather | |||
| than requiring a standards track RFC). In addition, a few minor | than requiring a standards track RFC). In addition, a few minor | |||
| clarifications and editorial improvements were made. | clarifications and editorial improvements were made. | |||
| The remainder of this document is organized as follows. Section 2 | The remainder of this document is organized as follows. Section 2 | |||
| describes general extension mechanisms for the client hello and | describes general extension mechanisms for the client hello and | |||
| server hello handshake messages. Section 3 describes specific | server hello handshake messages. Section 3 describes specific | |||
| extensions to TLS 1.0. Section 4 describes new error alerts for use | extensions to TLS. Section 4 describes new error alerts for use | |||
| with the TLS extensions. The final sections of the document address | with the TLS extensions. The final sections of the document address | |||
| IPR, security considerations, registration of the | IPR, security considerations, registration of the | |||
| application/pkix-pkipath MIME type, acknowledgements, and references. | application/pkix-pkipath MIME type, acknowledgements, and references. | |||
| 2. General Extension Mechanisms | 2. General Extension Mechanisms | |||
| This section presents general extension mechanisms for the TLS | This section presents general extension mechanisms for the TLS | |||
| handshake client hello and server hello messages. | handshake client hello and server hello messages. | |||
| These general extension mechanisms are necessary in order to enable | These general extension mechanisms are necessary in order to enable | |||
| skipping to change at page 5, line 29 ¶ | skipping to change at page 5, line 34 ¶ | |||
| Here the new "client_hello_extension_list" field contains a list of | Here the new "client_hello_extension_list" field contains a list of | |||
| extensions. The actual "Extension" format is defined in Section 2.3. | extensions. The actual "Extension" format is defined in Section 2.3. | |||
| In the event that a client requests additional functionality using | In the event that a client requests additional functionality using | |||
| the extended client hello, and this functionality is not supplied by | the extended client hello, and this functionality is not supplied by | |||
| the server, the client MAY abort the handshake. | the server, the client MAY abort the handshake. | |||
| Note that [TLS], Section 7.4.1.2, allows additional information to be | 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 | added to the client hello message. Thus the use of the extended | |||
| client hello defined above should not "break" existing TLS 1.0 | client hello defined above should not "break" existing TLS servers. | |||
| servers. | ||||
| A server that supports the extensions mechanism MUST accept only | A server that supports the extensions mechanism MUST accept only | |||
| client hello messages in either the original or extended ClientHello | client hello messages in either the original or extended ClientHello | |||
| format, and (as for all other messages) MUST check that the amount of | 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 | data in the message precisely matches one of these formats; if not | |||
| then it MUST send a fatal "decode_error" alert. This overrides the | then it MUST send a fatal "decode_error" alert. This overrides the | |||
| "Forward compatibility note" in [TLS]. | "Forward compatibility note" in [TLS]. | |||
| 2.2. Extended Server Hello | 2.2. Extended Server Hello | |||
| skipping to change at page 6, line 19 ¶ | skipping to change at page 6, line 19 ¶ | |||
| CipherSuite cipher_suite; | CipherSuite cipher_suite; | |||
| CompressionMethod compression_method; | CompressionMethod compression_method; | |||
| Extension server_hello_extension_list<0..2^16-1>; | Extension server_hello_extension_list<0..2^16-1>; | |||
| } ServerHello; | } ServerHello; | |||
| Here the new "server_hello_extension_list" field contains a list of | Here the new "server_hello_extension_list" field contains a list of | |||
| extensions. The actual "Extension" format is defined in Section 2.3. | extensions. The actual "Extension" format is defined in Section 2.3. | |||
| Note that the extended server hello message is only sent in response | Note that the extended server hello message is only sent in response | |||
| to an extended client hello message. This prevents the possibility | to an extended client hello message. This prevents the possibility | |||
| that the extended server hello message could "break" existing TLS 1.0 | that the extended server hello message could "break" existing TLS | |||
| clients. | clients. | |||
| 2.3. Hello Extensions | 2.3. Hello Extensions | |||
| The extension format for extended client hellos and extended server | The extension format for extended client hellos and extended server | |||
| hellos is: | hellos is: | |||
| struct { | struct { | |||
| ExtensionType extension_type; | ExtensionType extension_type; | |||
| opaque extension_data<0..2^16-1>; | opaque extension_data<0..2^16-1>; | |||
| skipping to change at page 7, line 5 ¶ | skipping to change at page 7, line 5 ¶ | |||
| http://www.iana.org/assignments/tls-extensions). See sections 5 and | http://www.iana.org/assignments/tls-extensions). See sections 5 and | |||
| 8 for more information on how new values are added. | 8 for more information on how new values are added. | |||
| Note that for all extension types (including those defined in | Note that for all extension types (including those defined in | |||
| future), the extension type MUST NOT appear in the extended server | future), the extension type MUST NOT appear in the extended server | |||
| hello unless the same extension type appeared in the corresponding | hello unless the same extension type appeared in the corresponding | |||
| client hello. Thus clients MUST abort the handshake if they receive | client hello. Thus clients MUST abort the handshake if they receive | |||
| an extension type in the extended server hello that they did not | an extension type in the extended server hello that they did not | |||
| request in the associated (extended) client hello. | request in the associated (extended) client hello. | |||
| Nonetheless "server initiated" extensions may be provided in the | Nonetheless "server oriented" extensions may be provided in the | |||
| future within this framework - such an extension, say of type x, | future within this framework - such an extension, say of type x, | |||
| would require the client to first send an extension of type x in the | would require the client to first send an extension of type x in the | |||
| (extended) client hello with empty extension_data to indicate that it | (extended) client hello with empty extension_data to indicate that it | |||
| supports the extension type. | supports the extension type. In this case the client is offering the | |||
| capability to understand the extension type, and the server is taking | ||||
| the client up on its offer. | ||||
| Also note that when multiple extensions of different types are | Also note that when multiple extensions of different types are | |||
| present in the extended client hello or the extended server hello, | present in the extended client hello or the extended server hello, | |||
| the extensions may appear in any order. There MUST NOT be more than | the extensions may appear in any order. There MUST NOT be more than | |||
| one extension of the same type. | one extension of the same type. | |||
| Finally note that an extended client hello may be sent both when | Finally note that an extended client hello may be sent both when | |||
| starting a new session and when requesting session resumption. | starting a new session and when requesting session resumption. | |||
| Indeed a client that requests resumption of a session does not in | Indeed a client that requests resumption of a session does not in | |||
| general know whether the server will accept this request, and | general know whether the server will accept this request, and | |||
| skipping to change at page 9, line 7 ¶ | skipping to change at page 9, line 7 ¶ | |||
| extension to provide maximum fragment length negotiation. Section | extension to provide maximum fragment length negotiation. Section | |||
| 3.3 describes the extension to allow client certificate URLs. | 3.3 describes the extension to allow client certificate URLs. | |||
| Section 3.4 describes the extension to allow a client to indicate | Section 3.4 describes the extension to allow a client to indicate | |||
| which CA root keys it possesses. Section 3.5 describes the extension | which CA root keys it possesses. Section 3.5 describes the extension | |||
| to allow the use of truncated HMAC. Section 3.6 describes the | to allow the use of truncated HMAC. Section 3.6 describes the | |||
| extension to support integration of certificate status information | extension to support integration of certificate status information | |||
| messages into TLS handshakes. | messages into TLS handshakes. | |||
| 3.1. Server Name Indication | 3.1. Server Name Indication | |||
| [TLS] does not provide a mechanism for a client to tell a server the | 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 | name of the server it is contacting. It may be desirable for clients | |||
| to provide this information to facilitate secure connections to | to provide this information to facilitate secure connections to | |||
| servers that host multiple 'virtual' servers at a single underlying | servers that host multiple 'virtual' servers at a single underlying | |||
| network address. | network address. | |||
| In order to provide the server name, clients MAY include an extension | In order to provide the server name, clients MAY include an extension | |||
| of type "server_name" in the (extended) client hello. The | of type "server_name" in the (extended) client hello. The | |||
| "extension_data" field of this extension SHALL contain | "extension_data" field of this extension SHALL contain | |||
| "ServerNameList" where: | "ServerNameList" where: | |||
| skipping to change at page 10, line 35 ¶ | skipping to change at page 10, line 35 ¶ | |||
| If an application negotiates a server name using an application | If an application negotiates a server name using an application | |||
| protocol, then upgrades to TLS, and a server_name extension is sent, | protocol, then upgrades to TLS, and a server_name extension is sent, | |||
| then the extension SHOULD contain the same name that was negotiated | then the extension SHOULD contain the same name that was negotiated | |||
| in the application protocol. If the server_name is established in | in the application protocol. If the server_name is established in | |||
| the TLS session handshake, the client SHOULD NOT attempt to request a | the TLS session handshake, the client SHOULD NOT attempt to request a | |||
| different server name at the application layer. | different server name at the application layer. | |||
| 3.2. Maximum Fragment Length Negotiation | 3.2. Maximum Fragment Length Negotiation | |||
| [TLS] specifies a fixed maximum plaintext fragment length of 2^14 | Without this extension, TLS specifies a fixed maximum plaintext | |||
| bytes. It may be desirable for constrained clients to negotiate a | fragment length of 2^14 bytes. It may be desirable for constrained | |||
| smaller maximum fragment length due to memory limitations or | clients to negotiate a smaller maximum fragment length due to memory | |||
| bandwidth limitations. | limitations or bandwidth limitations. | |||
| In order to negotiate smaller maximum fragment lengths, clients MAY | In order to negotiate smaller maximum fragment lengths, clients MAY | |||
| include an extension of type "max_fragment_length" in the (extended) | include an extension of type "max_fragment_length" in the (extended) | |||
| client hello. The "extension_data" field of this extension SHALL | client hello. The "extension_data" field of this extension SHALL | |||
| contain: | contain: | |||
| enum{ | enum{ | |||
| 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) | 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) | |||
| } MaxFragmentLength; | } MaxFragmentLength; | |||
| skipping to change at page 11, line 45 ¶ | skipping to change at page 11, line 45 ¶ | |||
| defined in [TLS], [KERB], and [AESSUITES]), and when null compression | 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 | 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 | 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 | 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 | receiving a TLS record layer message larger than 793 bytes may | |||
| discard the message and send a "record_overflow" alert, without | discard the message and send a "record_overflow" alert, without | |||
| decrypting the message. | decrypting the message. | |||
| 3.3. Client Certificate URLs | 3.3. Client Certificate URLs | |||
| [TLS] specifies that when client authentication is performed, client | Without this extension, TLS specifies that when client authentication | |||
| certificates are sent by clients to servers during the TLS handshake. | is performed, client certificates are sent by clients to servers during | |||
| It may be desirable for constrained clients to send certificate URLs | the TLS handshake. It may be desirable for constrained clients to send | |||
| in place of certificates, so that they do not need to store their | certificate URLs in place of certificates, so that they do not need to | |||
| certificates and can therefore save memory. | store their certificates and can therefore save memory. | |||
| In order to negotiate to send certificate URLs to a server, clients | In order to negotiate to send certificate URLs to a server, clients | |||
| MAY include an extension of type "client_certificate_url" in the | MAY include an extension of type "client_certificate_url" in the | |||
| (extended) client hello. The "extension_data" field of this | (extended) client hello. The "extension_data" field of this | |||
| extension SHALL be empty. | extension SHALL be empty. | |||
| (Note that it is necessary to negotiate use of client certificate | (Note that it is necessary to negotiate use of client certificate | |||
| URLs in order to avoid "breaking" existing TLS 1.0 servers.) | URLs in order to avoid "breaking" existing TLS servers.) | |||
| Servers that receive an extended client hello containing a | Servers that receive an extended client hello containing a | |||
| "client_certificate_url" extension, MAY indicate that they are | "client_certificate_url" extension, MAY indicate that they are | |||
| willing to accept certificate URLs by including an extension of type | willing to accept certificate URLs by including an extension of type | |||
| "client_certificate_url" in the (extended) server hello. The | "client_certificate_url" in the (extended) server hello. The | |||
| "extension_data" field of this extension SHALL be empty. | "extension_data" field of this extension SHALL be empty. | |||
| After negotiation of the use of client certificate URLs has been | After negotiation of the use of client certificate URLs has been | |||
| successfully completed (by exchanging hellos including | successfully completed (by exchanging hellos including | |||
| "client_certificate_url" extensions), clients MAY send a | "client_certificate_url" extensions), clients MAY send a | |||
| skipping to change at page 13, line 39 ¶ | skipping to change at page 13, line 33 ¶ | |||
| root certificate MAY be omitted from the chain, under the assumption | root certificate MAY be omitted from the chain, under the assumption | |||
| that the server must already possess it in order to validate it. | that the server must already possess it in order to validate it. | |||
| Servers receiving "CertificateURL" SHALL attempt to retrieve the | Servers receiving "CertificateURL" SHALL attempt to retrieve the | |||
| client's certificate chain from the URLs, and then process 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 | 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 | 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. | that URL and it matches the hash of the cached copy. | |||
| Servers that support this extension MUST support the http: URL scheme | Servers that support this extension MUST support the http: URL scheme | |||
| for certificate URLs, and MAY support other schemes. | for certificate URLs, and MAY support other schemes. Use of other | |||
| schemes than "http", "https", or "ftp" may create unexpected | ||||
| problems. | ||||
| If the protocol used is HTTP, then the HTTP server can be configured | ||||
| to use the Cache-Control and Expires directives described in [HTTP] | ||||
| to specify whether and for how long certificates or certificate | ||||
| chains should be cached. | ||||
| The TLS server is not required to follow HTTP redirects when | ||||
| retrieving the certificates or certificate chain. The URLs used in | ||||
| this extension SHOULD therefore be chosen not to depend on such | ||||
| redirects. | ||||
| If the protocol used to retrieve certificates or certificate chains | If the protocol used to retrieve certificates or certificate chains | |||
| returns a MIME formatted response (as HTTP does), then the following | returns a MIME formatted response (as HTTP does), then the following | |||
| MIME Content-Types SHALL be used: when a single X.509v3 certificate | MIME Content-Types SHALL be used: when a single X.509v3 certificate | |||
| is returned, the Content-Type is "application/pkix-cert" [PKIOP], and | is returned, the Content-Type is "application/pkix-cert" [PKIOP], and | |||
| when a chain of X.509v3 certificates is returned, the Content-Type is | when a chain of X.509v3 certificates is returned, the Content-Type is | |||
| "application/pkix-pkipath" (see Section 8). | "application/pkix-pkipath" (see Section 8). | |||
| If a SHA-1 hash is present for an URL, then the server MUST check | 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 | that the SHA-1 hash of the contents of the object retrieved from that | |||
| skipping to change at page 21, line 25 ¶ | skipping to change at page 21, line 25 ¶ | |||
| Security considerations for the extension mechanism in general, and | Security considerations for the extension mechanism in general, and | |||
| the design of new extensions, are described in the previous section. | the design of new extensions, are described in the previous section. | |||
| A security analysis of each of the extensions defined in this | A security analysis of each of the extensions defined in this | |||
| document is given below. | document is given below. | |||
| In general, implementers should continue to monitor the state of the | In general, implementers should continue to monitor the state of the | |||
| art, and address any weaknesses identified. | art, and address any weaknesses identified. | |||
| Additional security considerations are described in the TLS 1.0 RFC | Additional security considerations are described in the TLS 1.0 RFC | |||
| [TLS]. | [TLS] and the TLS 1.1 RFC [TLSbis]. | |||
| 6.1. Security of server_name | 6.1. Security of server_name | |||
| If a single server hosts several domains, then clearly it is | If a single server hosts several domains, then clearly it is | |||
| necessary for the owners of each domain to ensure that this satisfies | necessary for the owners of each domain to ensure that this satisfies | |||
| their security needs. Apart from this, server_name does not appear | their security needs. Apart from this, server_name does not appear | |||
| to introduce significant security issues. | to introduce significant security issues. | |||
| Implementations MUST ensure that a buffer overflow does not occur | Implementations MUST ensure that a buffer overflow does not occur | |||
| whatever the values of the length fields in server_name. | whatever the values of the length fields in server_name. | |||
| skipping to change at page 21, line 50 ¶ | skipping to change at page 21, line 50 ¶ | |||
| hostnames in TLS - in particular, the consequences of "spoofed" names | hostnames in TLS - in particular, the consequences of "spoofed" names | |||
| that are indistinguishable from another name when displayed or | that are indistinguishable from another name when displayed or | |||
| printed. It is recommended that server certificates not be issued | printed. It is recommended that server certificates not be issued | |||
| for internationalized hostnames unless procedures are in place to | for internationalized hostnames unless procedures are in place to | |||
| mitigate the risk of spoofed hostnames. | mitigate the risk of spoofed hostnames. | |||
| 6.2. Security of max_fragment_length | 6.2. Security of max_fragment_length | |||
| The maximum fragment length takes effect immediately, including for | The maximum fragment length takes effect immediately, including for | |||
| handshake messages. However, that does not introduce any security | handshake messages. However, that does not introduce any security | |||
| complications that are not already present in TLS, since [TLS] | complications that are not already present in TLS, since TLS | |||
| requires implementations to be able to handle fragmented handshake | requires implementations to be able to handle fragmented handshake | |||
| messages. | messages. | |||
| Note that as described in section 3.2, once a non-null cipher suite | Note that as described in section 3.2, once a non-null cipher suite | |||
| has been activated, the effective maximum fragment length depends on | has been activated, the effective maximum fragment length depends on | |||
| the cipher suite and compression method, as well as on the negotiated | the cipher suite and compression method, as well as on the negotiated | |||
| max_fragment_length. This must be taken into account when sizing | max_fragment_length. This must be taken into account when sizing | |||
| buffers, and checking for buffer overflow. | buffers, and checking for buffer overflow. | |||
| 6.3. Security of client_certificate_url | 6.3. Security of client_certificate_url | |||
| skipping to change at page 24, line 43 ¶ | skipping to change at page 24, line 43 ¶ | |||
| None of the extensions defined here directly use strings subject to | None of the extensions defined here directly use strings subject to | |||
| localization. Domain Name System (DNS) hostnames are encoded using | localization. Domain Name System (DNS) hostnames are encoded using | |||
| UTF-8. If future extensions use text strings, then | UTF-8. If future extensions use text strings, then | |||
| internationalization should be considered in their design. | internationalization should be considered in their design. | |||
| 8. IANA Considerations | 8. IANA Considerations | |||
| Sections 2.3 and 5 describes a registry of ExtensionType values to be | Sections 2.3 and 5 describes a registry of ExtensionType values to be | |||
| maintained by the IANA. ExtensionType values are to be assigned via | maintained by the IANA. ExtensionType values are to be assigned via | |||
| IETF Consensus as defined in RFC 2434 [IANA]. | IETF Consensus as defined in RFC 2434 [IANA]. The initial registry | |||
| corresponds to the definition of "ExtensionType" in Section 2.3. | ||||
| The MIME type "application/pkix-pkipath" has been registered by the | The MIME type "application/pkix-pkipath" has been registered by the | |||
| IANA with the following template: | IANA with the following template: | |||
| To: ietf-types@iana.org Subject: Registration of MIME media type | To: ietf-types@iana.org Subject: Registration of MIME media type | |||
| application/pkix-pkipath | application/pkix-pkipath | |||
| MIME media type name: application | MIME media type name: application | |||
| MIME subtype name: pkix-pkipath | MIME subtype name: pkix-pkipath | |||
| Required parameters: none | Required parameters: none | |||
| Optional parameters: version (default value is "1") | Optional parameters: version (default value is "1") | |||
| Encoding considerations: | Encoding considerations: | |||
| This MIME type is a DER encoding of the ASN.1 type PkiPath, | This MIME type is a DER encoding of the ASN.1 type PkiPath, | |||
| defined as follows: | defined as follows: | |||
| PkiPath ::= SEQUENCE OF Certificate | PkiPath ::= SEQUENCE OF Certificate | |||
| PkiPath is used to represent a certification path. Within the | PkiPath is used to represent a certification path. Within the | |||
| sequence, the order of certificates is such that the subject of | sequence, the order of certificates is such that the subject of | |||
| the first certificate is the issuer of the second certificate, | the first certificate is the issuer of the second certificate, | |||
| skipping to change at page 26, line 17 ¶ | skipping to change at page 26, line 17 ¶ | |||
| Further parsing is required to distinguish from other ASN.1 | Further parsing is required to distinguish from other ASN.1 | |||
| types. | types. | |||
| File extension(s): .pkipath | File extension(s): .pkipath | |||
| Macintosh File Type Code(s): not specified | Macintosh File Type Code(s): not specified | |||
| Person & email address to contact for further information: | Person & email address to contact for further information: | |||
| Magnus Nystrom <magnus@rsasecurity.com> | Magnus Nystrom <magnus@rsasecurity.com> | |||
| Intended usage: COMMON | Intended usage: COMMON | |||
| Author/Change controller: | Change controller: | |||
| Magnus Nystrom <magnus@rsasecurity.com> | IESG <iesg@ietf.org> | |||
| 9. Intellectual Property Rights | 9. Intellectual Property Rights | |||
| The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
| Intellectual Property Rights or other rights that might be claimed | Intellectual Property Rights or other rights that might be claimed | |||
| to pertain to the implementation or use of the technology | to pertain to the implementation or use of the technology | |||
| described in this document or the extent to which any license | described in this document or the extent to which any license | |||
| under such rights might or might not be available; nor does it | under such rights might or might not be available; nor does it | |||
| represent that it has made any independent effort to identify any | represent that it has made any independent effort to identify any | |||
| such rights. Information on the procedures with respect to rights | such rights. Information on the procedures with respect to rights | |||
| skipping to change at page 27, line 43 ¶ | skipping to change at page 27, line 37 ¶ | |||
| RFC 2585, May 1999. | RFC 2585, May 1999. | |||
| [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet | [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet | |||
| Public Key Infrastructure - Certificate and | Public Key Infrastructure - Certificate and | |||
| Certificate Revocation List (CRL) Profile", RFC 3280, | Certificate Revocation List (CRL) Profile", RFC 3280, | |||
| April 2002. | April 2002. | |||
| [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version | [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version | |||
| 1.0", RFC 2246, January 1999. | 1.0", RFC 2246, January 1999. | |||
| [TLSbis] Dierks, T. and E. Rescorla, "The TLS Protocol Version | ||||
| 1.1", IETF TLS WG Internet-draft, | ||||
| draft-ietf-tls-rfc2246-bis-13.txt, June 2005. | ||||
| [URI] Berners-Lee, T., Fielding, R. and L. Masinter, | [URI] Berners-Lee, T., Fielding, R. and L. Masinter, | |||
| "Uniform Resource Identifiers (URI): Generic Syntax", | "Uniform Resource Identifiers (URI): Generic Syntax", | |||
| RFC 2396, August 1998. | RFC 2396, August 1998. | |||
| [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO | [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO | |||
| 10646", RFC 3629, November 2003. | 10646", RFC 3629, November 2003. | |||
| [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- | [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- | |||
| 8:2001, "Information Systems - Open Systems | 8:2001, "Information Systems - Open Systems | |||
| Interconnection - The Directory: Public key and | Interconnection - The Directory: Public key and | |||
| End of changes. 27 change blocks. | ||||
| 42 lines changed or deleted | 60 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||