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