idnits 2.17.1 draft-ietf-tls-rfc3546bis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1361. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1242. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1352), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document obsoletes RFC3546, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2246, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 788 has weird spacing: '...ensions reque...' (Using the creation date from RFC2246, updated by this document, for RFC5378 checks: 1996-12-03) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2005) is 6791 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '20' on line 579 ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. 'HMAC') ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3490 (ref. 'IDNA') (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Downref: Normative reference to an Historic draft: draft-ietf-tls-rfc2246-bis (ref. 'TLSbis') ** Obsolete normative reference: RFC 2396 (ref. 'URI') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-4th' -- Possible downref: Non-RFC (?) normative reference: ref. 'X509-4th-TC1' -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. 'AESSUITES') (Obsoleted by RFC 5246) -- Obsolete informational reference (is this intentional?): RFC 3546 (Obsoleted by RFC 4366) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group S. Blake-Wilson 2 Internet-Draft BCI 3 Obsoletes: 3546 (if approved) M. Nystrom 4 Updates: 2246 & [TBD for TLS1.1 RFC] RSA Security 5 Category: Standards Track D. Hopwood 6 Expires: March 2006 Independent Consultant 7 J. Mikkelsen 8 Transactionware 9 T. Wright 10 Vodafone 11 September 2005 13 Transport Layer Security (TLS) Extensions 14 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at http:// 34 www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire in March 2006. 41 Copyright Notice 43 Copyright (C) The Internet Society (2005). All Rights Reserved. 45 Abstract 47 This document describes extensions that may be used to add 48 functionality to Transport Layer Security (TLS). It provides both 49 generic extension mechanisms for the TLS handshake client and server 50 hellos, and specific extensions using these generic mechanisms. 52 The extensions may be used by TLS clients and servers. The 53 extensions are backwards compatible - communication is possible 54 between TLS clients that support the extensions and TLS 55 servers that do not support the extensions, and vice versa. 57 Conventions used in this Document 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in BCP 14, RFC 2119 62 [KEYWORDS]. 64 Table of Contents 66 1. Introduction ............................................. 2 67 2. General Extension Mechanisms ............................. 4 68 2.1. Extended Client Hello ............................... 5 69 2.2. Extended Server Hello ............................... 5 70 2.3. Hello Extensions .................................... 6 71 2.4. Extensions to the handshake protocol ................ 7 72 3. Specific Extensions ...................................... 8 73 3.1. Server Name Indication .............................. 8 74 3.2. Maximum Fragment Length Negotiation ................. 10 75 3.3. Client Certificate URLs ............................. 11 76 3.4. Trusted CA Indication ............................... 14 77 3.5. Truncated HMAC ...................................... 15 78 3.6. Certificate Status Request........................... 16 79 4. Error alerts .............................................. 18 80 5. Procedure for Defining New Extensions...................... 20 81 6. Security Considerations .................................. 21 82 6.1. Security of server_name ............................. 21 83 6.2. Security of max_fragment_length ..................... 21 84 6.3. Security of client_certificate_url .................. 22 85 6.4. Security of trusted_ca_keys ......................... 23 86 6.5. Security of truncated_hmac .......................... 23 87 6.6. Security of status_request .......................... 24 88 7. Internationalization Considerations ...................... 24 89 8. IANA Considerations ...................................... 24 90 9. Intellectual Property Rights ............................. 26 91 10. Acknowledgments .......................................... 26 92 11. Normative References ..................................... 27 93 12. Informative References ................................... 28 94 13. Authors' Addresses ....................................... 28 95 14. Full Copyright Statement ................................. 29 97 1. Introduction 99 This document describes extensions that may be used to add 100 functionality to Transport Layer Security (TLS). It provides both 101 generic extension mechanisms for the TLS handshake client and server 102 hellos, and specific extensions using these generic mechanisms. 104 TLS is now used in an increasing variety of operational environments 105 - many of which were not envisioned when the original design criteria 106 for TLS were determined. The extensions introduced in this document 107 are designed to enable TLS to operate as effectively as possible in 108 new environments like wireless networks. 110 Wireless environments often suffer from a number of constraints not 111 commonly present in wired environments. These constraints may 112 include bandwidth limitations, computational power limitations, 113 memory limitations, and battery life limitations. 115 The extensions described here focus on extending the functionality 116 provided by the TLS protocol message formats. Other issues, such as 117 the addition of new cipher suites, are deferred. 119 Specifically, the extensions described in this document: 121 - Allow TLS clients to provide to the TLS server the name of the 122 server they are contacting. This functionality is desirable to 123 facilitate secure connections to servers that host multiple 124 'virtual' servers at a single underlying network address. 126 - Allow TLS clients and servers to negotiate the maximum fragment 127 length to be sent. This functionality is desirable as a result of 128 memory constraints among some clients, and bandwidth constraints 129 among some access networks. 131 - Allow TLS clients and servers to negotiate the use of client 132 certificate URLs. This functionality is desirable in order to 133 conserve memory on constrained clients. 135 - Allow TLS clients to indicate to TLS servers which CA root keys 136 they possess. This functionality is desirable in order to prevent 137 multiple handshake failures involving TLS clients that are only 138 able to store a small number of CA root keys due to memory 139 limitations. 141 - Allow TLS clients and servers to negotiate the use of truncated 142 MACs. This functionality is desirable in order to conserve 143 bandwidth in constrained access networks. 145 - Allow TLS clients and servers to negotiate that the server sends 146 the client certificate status information (e.g., an Online 147 Certificate Status Protocol (OCSP) [OCSP] response) during a TLS 148 handshake. This functionality is desirable in order to avoid 149 sending a Certificate Revocation List (CRL) over a constrained 150 access network and therefore save bandwidth. 152 In order to support the extensions above, general extension 153 mechanisms for the client hello message and the server hello message 154 are introduced. 156 The extensions described in this document may be used by TLS clients 157 and servers. The extensions are designed to be backwards compatible 158 - meaning that TLS clients that support the extensions can talk to 159 TLS servers that do not support the extensions, and vice versa. The 160 document therefore updates TLS 1.0 [TLS] and TLS 1.1 [TLSbis]. 162 Backwards compatibility is primarily achieved via two considerations: 164 - Clients typically request the use of extensions via the extended 165 client hello message described in Section 2.1. TLS requires 166 servers to accept extended client hello messages, even if the 167 server does not "understand" the extension. 169 - For the specific extensions described here, no mandatory server 170 response is required when clients request extended functionality. 172 Essentially backwards compatibility is achieved based on the TLS 173 requirement that servers that are not "extensions-aware" ignore 174 data added to client hellos that they do not recognize -- see, for 175 example, Section 7.4.1.2 of [TLS]. 177 Note however, that although backwards compatibility is supported, 178 some constrained clients may be forced to reject communications with 179 servers that do not support the extensions as a result of the limited 180 capabilities of such clients. 182 This document is a revision of the RFC3546 [RFC3546]. The only 183 major change concerns the definition of new extensions. New 184 extensions can now be defined via the IETF Consensus Process (rather 185 than requiring a standards track RFC). In addition, a few minor 186 clarifications and editorial improvements were made. 188 The remainder of this document is organized as follows. Section 2 189 describes general extension mechanisms for the client hello and 190 server hello handshake messages. Section 3 describes specific 191 extensions to TLS. Section 4 describes new error alerts for use 192 with the TLS extensions. The final sections of the document address 193 IPR, security considerations, registration of the 194 application/pkix-pkipath MIME type, acknowledgements, and references. 196 2. General Extension Mechanisms 198 This section presents general extension mechanisms for the TLS 199 handshake client hello and server hello messages. 201 These general extension mechanisms are necessary in order to enable 202 clients and servers to negotiate whether to use specific extensions, 203 and how to use specific extensions. The extension formats described 204 are based on [MAILING LIST]. 206 Section 2.1 specifies the extended client hello message format, 207 Section 2.2 specifies the extended server hello message format, and 208 Section 2.3 describes the actual extension format used with the 209 extended client and server hellos. 211 2.1. Extended Client Hello 213 Clients MAY request extended functionality from servers by sending 214 the extended client hello message format in place of the client hello 215 message format. The extended client hello message format is: 217 struct { 218 ProtocolVersion client_version; 219 Random random; 220 SessionID session_id; 221 CipherSuite cipher_suites<2..2^16-1>; 222 CompressionMethod compression_methods<1..2^8-1>; 223 Extension client_hello_extension_list<0..2^16-1>; 224 } ClientHello; 226 Here the new "client_hello_extension_list" field contains a list of 227 extensions. The actual "Extension" format is defined in Section 2.3. 229 In the event that a client requests additional functionality using 230 the extended client hello, and this functionality is not supplied by 231 the server, the client MAY abort the handshake. 233 Note that [TLS], Section 7.4.1.2, allows additional information to be 234 added to the client hello message. Thus the use of the extended 235 client hello defined above should not "break" existing TLS servers. 237 A server that supports the extensions mechanism MUST accept only 238 client hello messages in either the original or extended ClientHello 239 format, and (as for all other messages) MUST check that the amount of 240 data in the message precisely matches one of these formats; if not 241 then it MUST send a fatal "decode_error" alert. This overrides the 242 "Forward compatibility note" in [TLS]. 244 2.2. Extended Server Hello 246 The extended server hello message format MAY be sent in place of the 247 server hello message when the client has requested extended 248 functionality via the extended client hello message specified in 249 Section 2.1. The extended server hello message format is: 251 struct { 252 ProtocolVersion server_version; 253 Random random; 254 SessionID session_id; 255 CipherSuite cipher_suite; 256 CompressionMethod compression_method; 257 Extension server_hello_extension_list<0..2^16-1>; 258 } ServerHello; 260 Here the new "server_hello_extension_list" field contains a list of 261 extensions. The actual "Extension" format is defined in Section 2.3. 263 Note that the extended server hello message is only sent in response 264 to an extended client hello message. This prevents the possibility 265 that the extended server hello message could "break" existing TLS 266 clients. 268 2.3. Hello Extensions 270 The extension format for extended client hellos and extended server 271 hellos is: 273 struct { 274 ExtensionType extension_type; 275 opaque extension_data<0..2^16-1>; 276 } Extension; 278 Here: 280 - "extension_type" identifies the particular extension type. 282 - "extension_data" contains information specific to the particular 283 extension type. 285 The extension types defined in this document are: 287 enum { 288 server_name(0), max_fragment_length(1), 289 client_certificate_url(2), trusted_ca_keys(3), 290 truncated_hmac(4), status_request(5), (65535) 291 } ExtensionType; 293 The list of defined extension types is maintained by the IANA. The 294 current list can be found at XXX (suggest 295 http://www.iana.org/assignments/tls-extensions). See sections 5 and 296 8 for more information on how new values are added. 298 Note that for all extension types (including those defined in 299 future), the extension type MUST NOT appear in the extended server 300 hello unless the same extension type appeared in the corresponding 301 client hello. Thus clients MUST abort the handshake if they receive 302 an extension type in the extended server hello that they did not 303 request in the associated (extended) client hello. 305 Nonetheless "server oriented" extensions may be provided in the 306 future within this framework - such an extension, say of type x, 307 would require the client to first send an extension of type x in the 308 (extended) client hello with empty extension_data to indicate that it 309 supports the extension type. In this case the client is offering the 310 capability to understand the extension type, and the server is taking 311 the client up on its offer. 313 Also note that when multiple extensions of different types are 314 present in the extended client hello or the extended server hello, 315 the extensions may appear in any order. There MUST NOT be more than 316 one extension of the same type. 318 Finally note that an extended client hello may be sent both when 319 starting a new session and when requesting session resumption. 320 Indeed a client that requests resumption of a session does not in 321 general know whether the server will accept this request, and 322 therefore it SHOULD send an extended client hello if it would 323 normally do so for a new session. In general the specification of 324 each extension type must include a discussion of the effect of the 325 extension both during new sessions and during resumed sessions. 327 2.4. Extensions to the handshake protocol 329 This document suggests the use of two new handshake messages, 330 "CertificateURL" and "CertificateStatus". These messages are 331 described in Section 3.3 and Section 3.6, respectively. The new 332 handshake message structure therefore becomes: 334 enum { 335 hello_request(0), client_hello(1), server_hello(2), 336 certificate(11), server_key_exchange (12), 337 certificate_request(13), server_hello_done(14), 338 certificate_verify(15), client_key_exchange(16), 339 finished(20), certificate_url(21), certificate_status(22), 340 (255) 341 } HandshakeType; 342 struct { 343 HandshakeType msg_type; /* handshake type */ 344 uint24 length; /* bytes in message */ 345 select (HandshakeType) { 346 case hello_request: HelloRequest; 347 case client_hello: ClientHello; 348 case server_hello: ServerHello; 349 case certificate: Certificate; 350 case server_key_exchange: ServerKeyExchange; 351 case certificate_request: CertificateRequest; 352 case server_hello_done: ServerHelloDone; 353 case certificate_verify: CertificateVerify; 354 case client_key_exchange: ClientKeyExchange; 355 case finished: Finished; 356 case certificate_url: CertificateURL; 357 case certificate_status: CertificateStatus; 358 } body; 359 } Handshake; 361 3. Specific Extensions 363 This section describes the specific TLS extensions specified in this 364 document. 366 Note that any messages associated with these extensions that are sent 367 during the TLS handshake MUST be included in the hash calculations 368 involved in "Finished" messages. 370 Note also that all the extensions defined in this Section are 371 relevant only when a session is initiated. When a client includes 372 one or more of the defined extension types in an extended client 373 hello while requesting session resumption: 375 - If the resumption request is denied, the use of the extensions 376 is negotiated as normal. 378 - If, on the other hand, the older session is resumed, then the 379 server MUST ignore the extensions and send a server hello containing 380 none of the extension types; in this case the functionality of these 381 extensions negotiated during the original session initiation is 382 applied to the resumed session. 384 Section 3.1 describes the extension of TLS to allow a client to 385 indicate which server it is contacting. Section 3.2 describes the 386 extension to provide maximum fragment length negotiation. Section 387 3.3 describes the extension to allow client certificate URLs. 388 Section 3.4 describes the extension to allow a client to indicate 389 which CA root keys it possesses. Section 3.5 describes the extension 390 to allow the use of truncated HMAC. Section 3.6 describes the 391 extension to support integration of certificate status information 392 messages into TLS handshakes. 394 3.1. Server Name Indication 396 TLS does not provide a mechanism for a client to tell a server the 397 name of the server it is contacting. It may be desirable for clients 398 to provide this information to facilitate secure connections to 399 servers that host multiple 'virtual' servers at a single underlying 400 network address. 402 In order to provide the server name, clients MAY include an extension 403 of type "server_name" in the (extended) client hello. The 404 "extension_data" field of this extension SHALL contain 405 "ServerNameList" where: 407 struct { 408 NameType name_type; 409 select (name_type) { 410 case host_name: HostName; 411 } name; 412 } ServerName; 414 enum { 415 host_name(0), (255) 416 } NameType; 418 opaque HostName<1..2^16-1>; 420 struct { 421 ServerName server_name_list<1..2^16-1> 422 } ServerNameList; 424 Currently the only server names supported are DNS hostnames, however 425 this does not imply any dependency of TLS on DNS, and other name 426 types may be added in the future (by an RFC that Updates this 427 document). TLS MAY treat provided server names as opaque data and 428 pass the names and types to the application. 430 "HostName" contains the fully qualified DNS hostname of the server, 431 as understood by the client. The hostname is represented as a byte 432 string using UTF-8 encoding [UTF8], without a trailing dot. 434 If the hostname labels contain only US-ASCII characters, then the 435 client MUST ensure that labels are separated only by the byte 0x2E, 436 representing the dot character U+002E (requirement 1 in section 3.1 437 of [IDNA] notwithstanding). If the server needs to match the HostName 438 against names that contain non-US-ASCII characters, it MUST perform 439 the conversion operation described in section 4 of [IDNA], treating 440 the HostName as a "query string" (i.e. the AllowUnassigned flag MUST 441 be set). Note that IDNA allows labels to be separated by any of the 442 Unicode characters U+002E, U+3002, U+FF0E, and U+FF61, therefore 443 servers MUST accept any of these characters as a label separator. If 444 the server only needs to match the HostName against names containing 445 exclusively ASCII characters, it MUST compare ASCII names case- 446 insensitively. 448 Literal IPv4 and IPv6 addresses are not permitted in "HostName". 450 It is RECOMMENDED that clients include an extension of type 451 "server_name" in the client hello whenever they locate a server by a 452 supported name type. 454 A server that receives a client hello containing the "server_name" 455 extension, MAY use the information contained in the extension to 456 guide its selection of an appropriate certificate to return to the 457 client, and/or other aspects of security policy. In this event, the 458 server SHALL include an extension of type "server_name" in the 459 (extended) server hello. The "extension_data" field of this 460 extension SHALL be empty. 462 If the server understood the client hello extension but does not 463 recognize the server name, it SHOULD send an "unrecognized_name" 464 alert (which MAY be fatal). 466 If an application negotiates a server name using an application 467 protocol, then upgrades to TLS, and a server_name extension is sent, 468 then the extension SHOULD contain the same name that was negotiated 469 in the application protocol. If the server_name is established in 470 the TLS session handshake, the client SHOULD NOT attempt to request a 471 different server name at the application layer. 473 3.2. Maximum Fragment Length Negotiation 475 Without this extension, TLS specifies a fixed maximum plaintext 476 fragment length of 2^14 bytes. It may be desirable for constrained 477 clients to negotiate a smaller maximum fragment length due to memory 478 limitations or bandwidth limitations. 480 In order to negotiate smaller maximum fragment lengths, clients MAY 481 include an extension of type "max_fragment_length" in the (extended) 482 client hello. The "extension_data" field of this extension SHALL 483 contain: 485 enum{ 486 2^9(1), 2^10(2), 2^11(3), 2^12(4), (255) 487 } MaxFragmentLength; 489 whose value is the desired maximum fragment length. The allowed 490 values for this field are: 2^9, 2^10, 2^11, and 2^12. 492 Servers that receive an extended client hello containing a 493 "max_fragment_length" extension, MAY accept the requested maximum 494 fragment length by including an extension of type 495 "max_fragment_length" in the (extended) server hello. The 496 "extension_data" field of this extension SHALL contain 497 "MaxFragmentLength" whose value is the same as the requested maximum 498 fragment length. 500 If a server receives a maximum fragment length negotiation request 501 for a value other than the allowed values, it MUST abort the 502 handshake with an "illegal_parameter" alert. Similarly, if a client 503 receives a maximum fragment length negotiation response that differs 504 from the length it requested, it MUST also abort the handshake with 505 an "illegal_parameter" alert. 507 Once a maximum fragment length other than 2^14 has been successfully 508 negotiated, the client and server MUST immediately begin fragmenting 509 messages (including handshake messages), to ensure that no fragment 510 larger than the negotiated length is sent. Note that TLS already 511 requires clients and servers to support fragmentation of handshake 512 messages. 514 The negotiated length applies for the duration of the session 515 including session resumptions. 517 The negotiated length limits the input that the record layer may 518 process without fragmentation (that is, the maximum value of 519 TLSPlaintext.length; see [TLS] section 6.2.1). Note that the output 520 of the record layer may be larger. For example, if the negotiated 521 length is 2^9=512, then for currently defined cipher suites (those 522 defined in [TLS], [KERB], and [AESSUITES]), and when null compression 523 is used, the record layer output can be at most 793 bytes: 5 bytes of 524 headers, 512 bytes of application data, 256 bytes of padding, and 20 525 bytes of MAC. That means that in this event a TLS record layer peer 526 receiving a TLS record layer message larger than 793 bytes may 527 discard the message and send a "record_overflow" alert, without 528 decrypting the message. 530 3.3. Client Certificate URLs 532 Without this extension, TLS specifies that when client authentication 533 is performed, client certificates are sent by clients to servers during 534 the TLS handshake. It may be desirable for constrained clients to send 535 certificate URLs in place of certificates, so that they do not need to 536 store their certificates and can therefore save memory. 538 In order to negotiate to send certificate URLs to a server, clients 539 MAY include an extension of type "client_certificate_url" in the 540 (extended) client hello. The "extension_data" field of this 541 extension SHALL be empty. 543 (Note that it is necessary to negotiate use of client certificate 544 URLs in order to avoid "breaking" existing TLS servers.) 546 Servers that receive an extended client hello containing a 547 "client_certificate_url" extension, MAY indicate that they are 548 willing to accept certificate URLs by including an extension of type 549 "client_certificate_url" in the (extended) server hello. The 550 "extension_data" field of this extension SHALL be empty. 552 After negotiation of the use of client certificate URLs has been 553 successfully completed (by exchanging hellos including 554 "client_certificate_url" extensions), clients MAY send a 555 "CertificateURL" message in place of a "Certificate" message: 557 enum { 558 individual_certs(0), pkipath(1), (255) 559 } CertChainType; 561 enum { 562 false(0), true(1) 563 } Boolean; 565 struct { 566 CertChainType type; 567 URLAndOptionalHash url_and_hash_list<1..2^16-1>; 568 } CertificateURL; 570 struct { 571 opaque url<1..2^16-1>; 572 Boolean hash_present; 573 select (hash_present) { 574 case false: struct {}; 575 case true: SHA1Hash; 576 } hash; 577 } URLAndOptionalHash; 579 opaque SHA1Hash[20]; 581 Here "url_and_hash_list" contains a sequence of URLs and optional 582 hashes. 584 When X.509 certificates are used, there are two possibilities: 586 - if CertificateURL.type is "individual_certs", each URL refers to a 587 single DER-encoded X.509v3 certificate, with the URL for the 588 client's certificate first, or 590 - if CertificateURL.type is "pkipath", the list contains a single 591 URL referring to a DER-encoded certificate chain, using the type 592 PkiPath described in Section 8. 594 When any other certificate format is used, the specification that 595 describes use of that format in TLS should define the encoding format 596 of certificates or certificate chains, and any constraint on their 597 ordering. 599 The hash corresponding to each URL at the client's discretion is 600 either not present or is the SHA-1 hash of the certificate or 601 certificate chain (in the case of X.509 certificates, the DER-encoded 602 certificate or the DER-encoded PkiPath). 604 Note that when a list of URLs for X.509 certificates is used, the 605 ordering of URLs is the same as that used in the TLS Certificate 606 message (see [TLS] Section 7.4.2), but opposite to the order in which 607 certificates are encoded in PkiPath. In either case, the self-signed 608 root certificate MAY be omitted from the chain, under the assumption 609 that the server must already possess it in order to validate it. 611 Servers receiving "CertificateURL" SHALL attempt to retrieve the 612 client's certificate chain from the URLs, and then process the 613 certificate chain as usual. A cached copy of the content of any URL 614 in the chain MAY be used, provided that a SHA-1 hash is present for 615 that URL and it matches the hash of the cached copy. 617 Servers that support this extension MUST support the http: URL scheme 618 for certificate URLs, and MAY support other schemes. Use of other 619 schemes than "http", "https", or "ftp" may create unexpected 620 problems. 622 If the protocol used is HTTP, then the HTTP server can be configured 623 to use the Cache-Control and Expires directives described in [HTTP] 624 to specify whether and for how long certificates or certificate 625 chains should be cached. 627 The TLS server is not required to follow HTTP redirects when 628 retrieving the certificates or certificate chain. The URLs used in 629 this extension SHOULD therefore be chosen not to depend on such 630 redirects. 632 If the protocol used to retrieve certificates or certificate chains 633 returns a MIME formatted response (as HTTP does), then the following 634 MIME Content-Types SHALL be used: when a single X.509v3 certificate 635 is returned, the Content-Type is "application/pkix-cert" [PKIOP], and 636 when a chain of X.509v3 certificates is returned, the Content-Type is 637 "application/pkix-pkipath" (see Section 8). 639 If a SHA-1 hash is present for an URL, then the server MUST check 640 that the SHA-1 hash of the contents of the object retrieved from that 641 URL (after decoding any MIME Content-Transfer-Encoding) matches the 642 given hash. If any retrieved object does not have the correct SHA-1 643 hash, the server MUST abort the handshake with a 644 "bad_certificate_hash_value" alert. 646 Note that clients may choose to send either "Certificate" or 647 "CertificateURL" after successfully negotiating the option to send 648 certificate URLs. The option to send a certificate is included to 649 provide flexibility to clients possessing multiple certificates. 651 If a server encounters an unreasonable delay in obtaining 652 certificates in a given CertificateURL, it SHOULD time out and signal 653 a "certificate_unobtainable" error alert. 655 3.4. Trusted CA Indication 657 Constrained clients that, due to memory limitations, possess only a 658 small number of CA root keys, may wish to indicate to servers which 659 root keys they possess, in order to avoid repeated handshake 660 failures. 662 In order to indicate which CA root keys they possess, clients MAY 663 include an extension of type "trusted_ca_keys" in the (extended) 664 client hello. The "extension_data" field of this extension SHALL 665 contain "TrustedAuthorities" where: 667 struct { 668 TrustedAuthority trusted_authorities_list<0..2^16-1>; 669 } TrustedAuthorities; 671 struct { 672 IdentifierType identifier_type; 673 select (identifier_type) { 674 case pre_agreed: struct {}; 675 case key_sha1_hash: SHA1Hash; 676 case x509_name: DistinguishedName; 677 case cert_sha1_hash: SHA1Hash; 678 } identifier; 679 } TrustedAuthority; 681 enum { 682 pre_agreed(0), key_sha1_hash(1), x509_name(2), 683 cert_sha1_hash(3), (255) 684 } IdentifierType; 686 opaque DistinguishedName<1..2^16-1>; 688 Here "TrustedAuthorities" provides a list of CA root key identifiers 689 that the client possesses. Each CA root key is identified via 690 either: 692 - "pre_agreed" - no CA root key identity supplied. 694 - "key_sha1_hash" - contains the SHA-1 hash of the CA root key. For 695 DSA and ECDSA keys, this is the hash of the "subjectPublicKey" 696 value. For RSA keys, the hash is of the big-endian byte string 697 representation of the modulus without any initial 0-valued bytes. 698 (This copies the key hash formats deployed in other environments.) 700 - "x509_name" - contains the DER-encoded X.509 DistinguishedName of 701 the CA. 703 - "cert_sha1_hash" - contains the SHA-1 hash of a DER-encoded 704 Certificate containing the CA root key. 706 Note that clients may include none, some, or all of the CA root keys 707 they possess in this extension. 709 Note also that it is possible that a key hash or a Distinguished Name 710 alone may not uniquely identify a certificate issuer - for example if 711 a particular CA has multiple key pairs - however here we assume this 712 is the case following the use of Distinguished Names to identify 713 certificate issuers in TLS. 715 The option to include no CA root keys is included to allow the client 716 to indicate possession of some pre-defined set of CA root keys. 718 Servers that receive a client hello containing the "trusted_ca_keys" 719 extension, MAY use the information contained in the extension to 720 guide their selection of an appropriate certificate chain to return 721 to the client. In this event, the server SHALL include an extension 722 of type "trusted_ca_keys" in the (extended) server hello. The 723 "extension_data" field of this extension SHALL be empty. 725 3.5. Truncated HMAC 727 Currently defined TLS cipher suites use the MAC construction HMAC 728 with either MD5 or SHA-1 [HMAC] to authenticate record layer 729 communications. In TLS the entire output of the hash function is 730 used as the MAC tag. However it may be desirable in constrained 731 environments to save bandwidth by truncating the output of the hash 732 function to 80 bits when forming MAC tags. 734 In order to negotiate the use of 80-bit truncated HMAC, clients MAY 735 include an extension of type "truncated_hmac" in the extended client 736 hello. The "extension_data" field of this extension SHALL be empty. 738 Servers that receive an extended hello containing a "truncated_hmac" 739 extension, MAY agree to use a truncated HMAC by including an 740 extension of type "truncated_hmac", with empty "extension_data", in 741 the extended server hello. 743 Note that if new cipher suites are added that do not use HMAC, and 744 the session negotiates one of these cipher suites, this extension 745 will have no effect. It is strongly recommended that any new cipher 746 suites using other MACs consider the MAC size as an integral part of 747 the cipher suite definition, taking into account both security and 748 bandwidth considerations. 750 If HMAC truncation has been successfully negotiated during a TLS 751 handshake, and the negotiated cipher suite uses HMAC, both the client 752 and the server pass this fact to the TLS record layer along with the 753 other negotiated security parameters. Subsequently during the 754 session, clients and servers MUST use truncated HMACs, calculated as 755 specified in [HMAC]. That is, CipherSpec.hash_size is 10 bytes, and 756 only the first 10 bytes of the HMAC output are transmitted and 757 checked. Note that this extension does not affect the calculation of 758 the PRF as part of handshaking or key derivation. 760 The negotiated HMAC truncation size applies for the duration of the 761 session including session resumptions. 763 3.6. Certificate Status Request 765 Constrained clients may wish to use a certificate-status protocol 766 such as OCSP [OCSP] to check the validity of server certificates, in 767 order to avoid transmission of CRLs and therefore save bandwidth on 768 constrained networks. This extension allows for such information to 769 be sent in the TLS handshake, saving roundtrips and resources. 771 In order to indicate their desire to receive certificate status 772 information, clients MAY include an extension of type 773 "status_request" in the (extended) client hello. The 774 "extension_data" field of this extension SHALL contain 775 "CertificateStatusRequest" where: 777 struct { 778 CertificateStatusType status_type; 779 select (status_type) { 780 case ocsp: OCSPStatusRequest; 781 } request; 782 } CertificateStatusRequest; 784 enum { ocsp(1), (255) } CertificateStatusType; 786 struct { 787 ResponderID responder_id_list<0..2^16-1>; 788 Extensions request_extensions; 789 } OCSPStatusRequest; 791 opaque ResponderID<1..2^16-1>; 792 opaque Extensions<0..2^16-1>; 794 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP 795 responders that the client trusts. A zero-length "responder_id_list" 796 sequence has the special meaning that the responders are implicitly 797 known to the server - e.g., by prior arrangement. "Extensions" is a 798 DER encoding of OCSP request extensions. 800 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as 801 defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero- 802 length "request_extensions" value means that there are no extensions 803 (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for 804 the "Extensions" type). 806 In the case of the "id-pkix-ocsp-nonce" OCSP extension, [OCSP] is 807 unclear about its encoding; for clarification, the nonce MUST be a 808 DER-encoded OCTET STRING, which is encapsulated as another OCTET 809 STRING (note that implementations based on an existing OCSP client 810 will need to be checked for conformance to this requirement). 812 Servers that receive a client hello containing the "status_request" 813 extension, MAY return a suitable certificate status response to the 814 client along with their certificate. If OCSP is requested, they 815 SHOULD use the information contained in the extension when selecting 816 an OCSP responder, and SHOULD include request_extensions in the OCSP 817 request. 819 Servers return a certificate response along with their certificate by 820 sending a "CertificateStatus" message immediately after the 821 "Certificate" message (and before any "ServerKeyExchange" or 822 "CertificateRequest" messages). If a server returns a 823 "CertificateStatus" message, then the server MUST have included an 824 extension of type "status_request" with empty "extension_data" in the 825 extended server hello. 827 struct { 828 CertificateStatusType status_type; 829 select (status_type) { 830 case ocsp: OCSPResponse; 831 } response; 832 } CertificateStatus; 834 opaque OCSPResponse<1..2^24-1>; 836 An "ocsp_response" contains a complete, DER-encoded OCSP response 837 (using the ASN.1 type OCSPResponse defined in [OCSP]). Note that 838 only one OCSP response may be sent. 840 The "CertificateStatus" message is conveyed using the handshake 841 message type "certificate_status". 843 Note that a server MAY also choose not to send a "CertificateStatus" 844 message, even if it receives a "status_request" extension in the 845 client hello message. 847 Note in addition that servers MUST NOT send the "CertificateStatus" 848 message unless it received a "status_request" extension in the client 849 hello message. 851 Clients requesting an OCSP response, and receiving an OCSP response 852 in a "CertificateStatus" message MUST check the OCSP response and 853 abort the handshake if the response is not satisfactory. 855 4. Error Alerts 857 This section defines new error alerts for use with the TLS extensions 858 defined in this document. 860 The following new error alerts are defined. To avoid "breaking" 861 existing clients and servers, these alerts MUST NOT be sent unless 862 the sending party has received an extended hello message from the 863 party they are communicating with. 865 - "unsupported_extension" - this alert is sent by clients that 866 receive an extended server hello containing an extension that they 867 did not put in the corresponding client hello (see Section 2.3). 868 This message is always fatal. 870 - "unrecognized_name" - this alert is sent by servers that receive a 871 server_name extension request, but do not recognize the server 872 name. This message MAY be fatal. 874 - "certificate_unobtainable" - this alert is sent by servers who are 875 unable to retrieve a certificate chain from the URL supplied by 876 the client (see Section 3.3). This message MAY be fatal - for 877 example if client authentication is required by the server for the 878 handshake to continue and the server is unable to retrieve the 879 certificate chain, it may send a fatal alert. 881 - "bad_certificate_status_response" - this alert is sent by clients 882 that receive an invalid certificate status response (see Section 883 3.6). This message is always fatal. 885 - "bad_certificate_hash_value" - this alert is sent by servers when 886 a certificate hash does not match a client provided 887 certificate_hash. This message is always fatal. 889 These error alerts are conveyed using the following syntax: 891 enum { 892 close_notify(0), 893 unexpected_message(10), 894 bad_record_mac(20), 895 decryption_failed(21), 896 record_overflow(22), 897 decompression_failure(30), 898 handshake_failure(40), 899 /* 41 is not defined, for historical reasons */ 900 bad_certificate(42), 901 unsupported_certificate(43), 902 certificate_revoked(44), 903 certificate_expired(45), 904 certificate_unknown(46), 905 illegal_parameter(47), 906 unknown_ca(48), 907 access_denied(49), 908 decode_error(50), 909 decrypt_error(51), 910 export_restriction(60), 911 protocol_version(70), 912 insufficient_security(71), 913 internal_error(80), 914 user_canceled(90), 915 no_renegotiation(100), 916 unsupported_extension(110), /* new */ 917 certificate_unobtainable(111), /* new */ 918 unrecognized_name(112), /* new */ 919 bad_certificate_status_response(113), /* new */ 920 bad_certificate_hash_value(114), /* new */ 921 (255) 922 } AlertDescription; 924 5. Procedure for Defining New Extensions 926 The list of extension types, as defined in Section 2.3, is 927 maintained by the Internet Assigned Numbers Authority (IANA). Thus 928 an application needs to be made to the IANA in order to obtain a new 929 extension type value. Since there are subtle (and not so subtle) 930 interactions that may occur in this protocol between new features and 931 existing features which may result in a significant reduction in 932 overall security, new values SHALL be defined only through the IETF 933 Consensus process specified in [IANA]. 935 (This means that new assignments can be made only via RFCs approved 936 by the IESG.) 938 The following considerations should be taken into account when 939 designing new extensions: 941 - All of the extensions defined in this document follow the 942 convention that for each extension that a client requests and that 943 the server understands, the server replies with an extension of 944 the same type. 946 - Some cases where a server does not agree to an extension are error 947 conditions, and some simply a refusal to support a particular 948 feature. In general error alerts should be used for the former, 949 and a field in the server extension response for the latter. 951 - Extensions should as far as possible be designed to prevent any 952 attack that forces use (or non-use) of a particular feature by 953 manipulation of handshake messages. This principle should be 954 followed regardless of whether the feature is believed to cause a 955 security problem. 957 Often the fact that the extension fields are included in the 958 inputs to the Finished message hashes will be sufficient, but 959 extreme care is needed when the extension changes the meaning of 960 messages sent in the handshake phase. Designers and implementors 961 should be aware of the fact that until the handshake has been 962 authenticated, active attackers can modify messages and insert, 963 remove, or replace extensions. 965 - It would be technically possible to use extensions to change major 966 aspects of the design of TLS; for example the design of cipher 967 suite negotiation. This is not recommended; it would be more 968 appropriate to define a new version of TLS - particularly since 969 the TLS handshake algorithms have specific protection against 970 version rollback attacks based on the version number, and the 971 possibility of version rollback should be a significant 972 consideration in any major design change. 974 6. Security Considerations 976 Security considerations for the extension mechanism in general, and 977 the design of new extensions, are described in the previous section. 978 A security analysis of each of the extensions defined in this 979 document is given below. 981 In general, implementers should continue to monitor the state of the 982 art, and address any weaknesses identified. 984 Additional security considerations are described in the TLS 1.0 RFC 985 [TLS] and the TLS 1.1 RFC [TLSbis]. 987 6.1. Security of server_name 989 If a single server hosts several domains, then clearly it is 990 necessary for the owners of each domain to ensure that this satisfies 991 their security needs. Apart from this, server_name does not appear 992 to introduce significant security issues. 994 Implementations MUST ensure that a buffer overflow does not occur 995 whatever the values of the length fields in server_name. 997 Although this document specifies an encoding for internationalized 998 hostnames in the server_name extension, it does not address any 999 security issues associated with the use of internationalized 1000 hostnames in TLS - in particular, the consequences of "spoofed" names 1001 that are indistinguishable from another name when displayed or 1002 printed. It is recommended that server certificates not be issued 1003 for internationalized hostnames unless procedures are in place to 1004 mitigate the risk of spoofed hostnames. 1006 6.2. Security of max_fragment_length 1008 The maximum fragment length takes effect immediately, including for 1009 handshake messages. However, that does not introduce any security 1010 complications that are not already present in TLS, since TLS 1011 requires implementations to be able to handle fragmented handshake 1012 messages. 1014 Note that as described in section 3.2, once a non-null cipher suite 1015 has been activated, the effective maximum fragment length depends on 1016 the cipher suite and compression method, as well as on the negotiated 1017 max_fragment_length. This must be taken into account when sizing 1018 buffers, and checking for buffer overflow. 1020 6.3. Security of client_certificate_url 1022 There are two major issues with this extension. 1024 The first major issue is whether or not clients should include 1025 certificate hashes when they send certificate URLs. 1027 When client authentication is used *without* the 1028 client_certificate_url extension, the client certificate chain is 1029 covered by the Finished message hashes. The purpose of including 1030 hashes and checking them against the retrieved certificate chain, is 1031 to ensure that the same property holds when this extension is used - 1032 i.e., that all of the information in the certificate chain retrieved 1033 by the server is as the client intended. 1035 On the other hand, omitting certificate hashes enables functionality 1036 that is desirable in some circumstances - for example clients can be 1037 issued daily certificates that are stored at a fixed URL and need not 1038 be provided to the client. Clients that choose to omit certificate 1039 hashes should be aware of the possibility of an attack in which the 1040 attacker obtains a valid certificate on the client's key that is 1041 different from the certificate the client intended to provide. 1042 Although TLS uses both MD5 and SHA-1 hashes in several other places, 1043 this was not believed to be necessary here. The property required of 1044 SHA-1 is second pre-image resistance. 1046 The second major issue is that support for client_certificate_url 1047 involves the server acting as a client in another URL protocol. The 1048 server therefore becomes subject to many of the same security 1049 concerns that clients of the URL scheme are subject to, with the 1050 added concern that the client can attempt to prompt the server to 1051 connect to some, possibly weird-looking URL. 1053 In general this issue means that an attacker might use the server to 1054 indirectly attack another host that is vulnerable to some security 1055 flaw. It also introduces the possibility of denial of service 1056 attacks in which an attacker makes many connections to the server, 1057 each of which results in the server attempting a connection to the 1058 target of the attack. 1060 Note that the server may be behind a firewall or otherwise able to 1061 access hosts that would not be directly accessible from the public 1062 Internet; this could exacerbate the potential security and denial of 1063 service problems described above, as well as allowing the existence 1064 of internal hosts to be confirmed when they would otherwise be 1065 hidden. 1067 The detailed security concerns involved will depend on the URL 1068 schemes supported by the server. In the case of HTTP, the concerns 1069 are similar to those that apply to a publicly accessible HTTP proxy 1070 server. In the case of HTTPS, the possibility for loops and 1071 deadlocks to be created exists and should be addressed. In the case 1072 of FTP, attacks similar to FTP bounce attacks arise. 1074 As a result of this issue, it is RECOMMENDED that the 1075 client_certificate_url extension should have to be specifically 1076 enabled by a server administrator, rather than being enabled by 1077 default. It is also RECOMMENDED that URI protocols be enabled by the 1078 administrator individually, and only a minimal set of protocols be 1079 enabled, with unusual protocols offering limited security or whose 1080 security is not well-understood being avoided. 1082 As discussed in [URI], URLs that specify ports other than the default 1083 may cause problems, as may very long URLs (which are more likely to 1084 be useful in exploiting buffer overflow bugs). 1086 Also note that HTTP caching proxies are common on the Internet, and 1087 some proxies do not check for the latest version of an object 1088 correctly. If a request using HTTP (or another caching protocol) 1089 goes through a misconfigured or otherwise broken proxy, the proxy may 1090 return an out-of-date response. 1092 6.4. Security of trusted_ca_keys 1094 It is possible that which CA root keys a client possesses could be 1095 regarded as confidential information. As a result, the CA root key 1096 indication extension should be used with care. 1098 The use of the SHA-1 certificate hash alternative ensures that each 1099 certificate is specified unambiguously. As for the previous 1100 extension, it was not believed necessary to use both MD5 and SHA-1 1101 hashes. 1103 6.5. Security of truncated_hmac 1105 It is possible that truncated MACs are weaker than "un-truncated" 1106 MACs. However, no significant weaknesses are currently known or 1107 expected to exist for HMAC with MD5 or SHA-1, truncated to 80 bits. 1109 Note that the output length of a MAC need not be as long as the 1110 length of a symmetric cipher key, since forging of MAC values cannot 1111 be done off-line: in TLS, a single failed MAC guess will cause the 1112 immediate termination of the TLS session. 1114 Since the MAC algorithm only takes effect after all handshake 1115 messages that affect extension parameters have been authenticated by 1116 the hashes in the Finished messages, it is not possible for an active 1117 attacker to force negotiation of the truncated HMAC extension where it 1118 would not otherwise be used (to the extent that the handshake 1119 authentication is secure). Therefore, in the event that any security 1120 problem were found with truncated HMAC in future, if either the client 1121 or the server for a given session were updated to take into account 1122 the problem, they would be able to veto use of this extension. 1124 6.6. Security of status_request 1126 If a client requests an OCSP response, it must take into account that 1127 an attacker's server using a compromised key could (and probably 1128 would) pretend not to support the extension. A client that requires 1129 OCSP validation of certificates SHOULD either contact the OCSP server 1130 directly in this case, or abort the handshake. 1132 Use of the OCSP nonce request extension (id-pkix-ocsp-nonce) may 1133 improve security against attacks that attempt to replay OCSP 1134 responses; see section 4.4.1 of [OCSP] for further details. 1136 7. Internationalization Considerations 1138 None of the extensions defined here directly use strings subject to 1139 localization. Domain Name System (DNS) hostnames are encoded using 1140 UTF-8. If future extensions use text strings, then 1141 internationalization should be considered in their design. 1143 8. IANA Considerations 1145 Sections 2.3 and 5 describes a registry of ExtensionType values to be 1146 maintained by the IANA. ExtensionType values are to be assigned via 1147 IETF Consensus as defined in RFC 2434 [IANA]. The initial registry 1148 corresponds to the definition of "ExtensionType" in Section 2.3. 1150 The MIME type "application/pkix-pkipath" has been registered by the 1151 IANA with the following template: 1153 To: ietf-types@iana.org Subject: Registration of MIME media type 1154 application/pkix-pkipath 1156 MIME media type name: application 1157 MIME subtype name: pkix-pkipath 1158 Required parameters: none 1159 Optional parameters: version (default value is "1") 1161 Encoding considerations: 1162 This MIME type is a DER encoding of the ASN.1 type PkiPath, 1163 defined as follows: 1164 PkiPath ::= SEQUENCE OF Certificate 1165 PkiPath is used to represent a certification path. Within the 1166 sequence, the order of certificates is such that the subject of 1167 the first certificate is the issuer of the second certificate, 1168 etc. 1170 This is identical to the definition published in [X509-4th-TC1]; 1171 note that it is different from that in [X509-4th]. 1173 All Certificates MUST conform to [PKIX]. (This should be 1174 interpreted as a requirement to encode only PKIX-conformant 1175 certificates using this type. It does not necessarily require 1176 that all certificates that are not strictly PKIX-conformant must 1177 be rejected by relying parties, although the security consequences 1178 of accepting any such certificates should be considered 1179 carefully.) 1181 DER (as opposed to BER) encoding MUST be used. If this type is 1182 sent over a 7-bit transport, base64 encoding SHOULD be used. 1184 Security considerations: 1185 The security considerations of [X509-4th] and [PKIX] (or any 1186 updates to them) apply, as well as those of any protocol that uses 1187 this type (e.g., TLS). 1189 Note that this type only specifies a certificate chain that can be 1190 assessed for validity according to the relying party's existing 1191 configuration of trusted CAs; it is not intended to be used to 1192 specify any change to that configuration. 1194 Interoperability considerations: 1195 No specific interoperability problems are known with this type, 1196 but for recommendations relating to X.509 certificates in general, 1197 see [PKIX]. 1199 Published specification: this memo, and [PKIX]. 1201 Applications which use this media type: TLS. It may also be used by 1202 other protocols, or for general interchange of PKIX certificate 1203 chains. 1205 Additional information: 1206 Magic number(s): DER-encoded ASN.1 can be easily recognized. 1207 Further parsing is required to distinguish from other ASN.1 1208 types. 1209 File extension(s): .pkipath 1210 Macintosh File Type Code(s): not specified 1212 Person & email address to contact for further information: 1213 Magnus Nystrom 1215 Intended usage: COMMON 1217 Change controller: 1218 IESG 1220 9. Intellectual Property Rights 1222 The IETF takes no position regarding the validity or scope of any 1223 Intellectual Property Rights or other rights that might be claimed 1224 to pertain to the implementation or use of the technology 1225 described in this document or the extent to which any license 1226 under such rights might or might not be available; nor does it 1227 represent that it has made any independent effort to identify any 1228 such rights. Information on the procedures with respect to rights 1229 in RFC documents can be found in BCP 78 and BCP 79. 1231 Copies of IPR disclosures made to the IETF Secretariat and any 1232 assurances of licenses to be made available, or the result of an 1233 attempt made to obtain a general license or permission for the use 1234 of such proprietary rights by implementers or users of this 1235 specification can be obtained from the IETF on-line IPR repository 1236 at http://www.ietf.org/ipr. 1238 The IETF invites any interested party to bring to its attention 1239 any copyrights, patents or patent applications, or other 1240 proprietary rights that may cover technology that may be required 1241 to implement this standard. Please address the information to the 1242 IETF at ietf-ipr@ietf.org. 1244 10. Acknowledgments 1246 The authors wish to thank the TLS Working Group and the WAP Security 1247 Group. This document is based on discussion within these groups. 1249 11. Normative References 1251 [HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: 1252 Keyed-hashing for message authentication", RFC 2104, 1253 February 1997. 1255 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1256 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1257 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1259 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing 1260 an IANA Considerations Section in RFCs", RFC 2434, 1261 October 1998. 1263 [IDNA] Faltstrom, P., Hoffman, P. and A. Costello, 1264 "Internationalizing Domain Names in Applications 1265 (IDNA)", RFC 3490, March 2003. 1267 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 1268 Requirement Levels", BCP 14, RFC 2119, March 1997. 1270 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and 1271 C. Adams, "Internet X.509 Public Key Infrastructure: 1272 Online Certificate Status Protocol - OCSP", RFC 2560, 1273 June 1999. 1275 [PKIOP] Housley, R. and P. Hoffman, "Internet X.509 Public Key 1276 Infrastructure - Operation Protocols: FTP and HTTP", 1277 RFC 2585, May 1999. 1279 [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 1280 Public Key Infrastructure - Certificate and 1281 Certificate Revocation List (CRL) Profile", RFC 3280, 1282 April 2002. 1284 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1285 1.0", RFC 2246, January 1999. 1287 [TLSbis] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1288 1.1", IETF TLS WG Internet-draft, 1289 draft-ietf-tls-rfc2246-bis-13.txt, June 2005. 1291 [URI] Berners-Lee, T., Fielding, R. and L. Masinter, 1292 "Uniform Resource Identifiers (URI): Generic Syntax", 1293 RFC 2396, August 1998. 1295 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 1296 10646", RFC 3629, November 2003. 1298 [X509-4th] ITU-T Recommendation X.509 (2000) | ISO/IEC 9594- 1299 8:2001, "Information Systems - Open Systems 1300 Interconnection - The Directory: Public key and 1301 attribute certificate frameworks." 1303 [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001) | 1304 ISO/IEC 9594-8:2001/Cor.1:2002, Technical Corrigendum 1305 1 to ISO/IEC 9594:8:2001. 1307 12. Informative References 1309 [AESSUITES] Chown, P., "Advanced Encryption Standard (AES) 1310 Ciphersuites for Transport Layer Security (TLS)", RFC 1311 3268, June 2002. 1313 [KERB] Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher 1314 Suites to Transport Layer Security (TLS)", RFC 2712, 1315 October 1999. 1317 [MAILING LIST] J. Mikkelsen, R. Eberhard, and J. Kistler, "General 1318 ClientHello extension mechanism and virtual hosting," 1319 ietf-tls mailing list posting, August 14, 2000. 1321 [RFC3546] S. Blake-Wilson, M.Nystrom, D. Hopwood, J. Mikkelsen, 1322 and T. Wright, "Transport Layer Security (TLS) 1323 Extensions", RFC 3546, June 2003. 1325 13. Authors' Addresses 1327 Simon Blake-Wilson 1328 BCI 1329 EMail: sblakewilson@bcisse.com 1331 Magnus Nystrom 1332 RSA Security 1333 EMail: magnus@rsasecurity.com 1335 David Hopwood 1336 Independent Consultant 1337 EMail: david.hopwood@blueyonder.co.uk 1339 Jan Mikkelsen 1340 Transactionware 1341 EMail: janm@transactionware.com 1343 Tim Wright 1344 Vodafone 1345 EMail: timothy.wright@vodafone.com 1347 14. Full Copyright Statement 1349 Copyright (C) The Internet Society (2005). This document is 1350 subject to the rights, licenses and restrictions contained in BCP 1351 78, and except as set forth therein, the authors retain all their 1352 rights. 1354 This document and the information contained herein are provided 1355 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1356 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1357 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1358 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 1359 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 1360 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1361 PARTICULAR PURPOSE. 1363 Acknowledgement 1365 Funding for the RFC Editor function is currently provided by the 1366 Internet Society.