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