idnits 2.17.00 (12 Aug 2021) /tmp/idnits7905/draft-ietf-tls-ecc-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 672 has weird spacing: '...rveType cur...' == Line 685 has weird spacing: '... opaque k <1....' == Line 687 has weird spacing: '... opaque k1 <1...' == Line 688 has weird spacing: '... opaque k2 <1...' == Line 689 has weird spacing: '... opaque k3 <1...' == (3 more instances...) -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'ChangeCipherSpec' on line 203 == Unused Reference: '15' is defined on line 1205, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2246 (ref. '2') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 3546 (ref. '3') (Obsoleted by RFC 4366) -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Obsolete informational reference (is this intentional?): RFC 3268 (ref. '14') (Obsoleted by RFC 5246) Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TLS Working Group V. Gupta 2 Internet-Draft Sun Labs 3 Expires: May 1, 2004 S. Blake-Wilson 4 BCI 5 B. Moeller 6 TBD 7 C. Hawk 8 Independent Consultant 9 N. Bolyard 10 Netscape 11 Nov. 2003 13 ECC Cipher Suites for TLS 14 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at http:// 32 www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on May 1, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2003). All Rights Reserved. 43 Abstract 45 This document describes new key exchange algorithms based on Elliptic 46 Curve Cryptography (ECC) for the TLS (Transport Layer Security) 47 protocol. In particular, it specifies the use of Elliptic Curve 48 Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of 49 Elliptic Curve Digital Signature Algorithm (ECDSA) as a new 50 authentication mechanism. 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in RFC 2119 [1]. 56 Please send comments on this document to the TLS mailing list. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 62 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 68 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 70 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . . 10 71 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 72 5. Data Structures and Computations . . . . . . . . . . . . . . 12 73 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . . 12 74 5.2 Server Hello Extensions . . . . . . . . . . . . . . . . . . 14 75 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15 76 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 16 77 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 20 78 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21 79 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 22 80 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . . 24 81 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . . 25 82 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . . 25 83 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 27 84 7. Security Considerations . . . . . . . . . . . . . . . . . . 29 85 8. Intellectual Property Rights . . . . . . . . . . . . . . . . 30 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 87 Normative References . . . . . . . . . . . . . . . . . . . . 32 88 Informative References . . . . . . . . . . . . . . . . . . . 33 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 90 Full Copyright Statement . . . . . . . . . . . . . . . . . . 35 92 1. Introduction 94 Elliptic Curve Cryptography (ECC) is emerging as an attractive 95 public-key cryptosystem for mobile/wireless environments. Compared 96 to currently prevalent cryptosystems such as RSA, ECC offers 97 equivalent security with smaller key sizes. This is illustrated in 98 the following table, based on [12], which gives approximate 99 comparable key sizes for symmetric- and asymmetric-key cryptosystems 100 based on the best-known algorithms for attacking them. 102 Symmetric | ECC | DH/DSA/RSA 103 -------------+---------+------------ 104 80 | 163 | 1024 105 112 | 233 | 2048 106 128 | 283 | 3072 107 192 | 409 | 7680 108 256 | 571 | 15360 110 Table 1: Comparable key sizes (in bits) 112 Smaller key sizes result in power, bandwidth and computational 113 savings that make ECC especially attractive for constrained 114 environments. 116 This document describes additions to TLS to support ECC. In 117 particular, it defines 119 o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement 120 scheme with long-term or ephemeral keys to establish the TLS 121 premaster secret, and 123 o the use of fixed-ECDH certificates and ECDSA for authentication of 124 TLS peers. 126 The remainder of this document is organized as follows. Section 2 127 provides an overview of ECC-based key exchange algorithms for TLS. 128 Section 3 describes the use of ECC certificates for client 129 authentication. TLS extensions that allow a client to negotiate the 130 use of specific curves and point formats are presented in Section 4. 131 Section 5 specifies various data structures needed for an ECC-based 132 handshake, their encoding in TLS messages and the processing of those 133 messages. Section 6 defines new ECC-based cipher suites and 134 identifies a small subset of these as recommended for all 135 implementations of this specification. Section 7, Section 8 and 136 Section 9 mention security considerations, intellectual property 137 rights, and acknowledgments, respectively. This is followed by a 138 list of references cited in this document and the authors' contact 139 information. 141 Implementation of this specification requires familiarity with TLS 142 [2], TLS extensions [3] and ECC [4][5][6][8] . 144 2. Key Exchange Algorithms 146 This document introduces five new ECC-based key exchange algorithms 147 for TLS. All of them use ECDH to compute the TLS premaster secret 148 and differ only in the lifetime of ECDH keys (long-term or ephemeral) 149 and the mechanism (if any) used to authenticate them. The derivation 150 of the TLS master secret from the premaster secret and the subsequent 151 generation of bulk encryption/MAC keys and initialization vectors is 152 independent of the key exchange algorithm and not impacted by the 153 introduction of ECC. 155 The table below summarizes the new key exchange algorithms which 156 mimic DH_DSS, DH_RSA, DHE_DSS, DHE_RSA and DH_anon (see [2]), 157 respectively. 159 Key 160 Exchange 161 Algorithm Description 162 --------- ----------- 164 ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. 166 ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. 168 ECDH_RSA Fixed ECDH with RSA-signed certificates. 170 ECDHE_RSA Ephemeral ECDH with RSA signatures. 172 ECDH_anon Anonymous ECDH, no signatures. 174 Table 2: ECC key exchange algorithms 176 Note that the anonymous key exchange algorithm does not provide 177 authentication of the server or the client. Like other anonymous TLS 178 key exchanges, it is subject to man-in-the-middle attacks. 179 Implementations of this algorithm SHOULD provide authentication by 180 other means. 182 Note that there is no structural difference between ECDH and ECDSA 183 keys. A certificate issuer may use X509.v3 keyUsage and 184 extendedKeyUsage extensions to restrict the use of an ECC public key 185 to certain computations. This document refers to an ECC key as ECDH- 186 capable if its use in ECDH is permitted. ECDSA-capable is defined 187 similarly. 189 Client Server 190 ------ ------ 192 ClientHello --------> 193 ServerHello 194 Certificate* 195 ServerKeyExchange* 196 CertificateRequest*+ 197 <-------- ServerHelloDone 198 Certificate*+ 199 ClientKeyExchange 200 CertificateVerify*+ 201 [ChangeCipherSpec] 202 Finished --------> 203 [ChangeCipherSpec] 204 <-------- Finished 206 Application Data <-------> Application Data 208 Figure 1: Message flow in a full TLS handshake 209 * message is not sent under some conditions 210 + message is not sent unless the client is 211 authenticated 213 Figure 1 shows all messages involved in the TLS key establishment 214 protocol (aka full handshake). The addition of ECC has direct impact 215 only on the ClientHello, the ServerHello, the server's Certificate 216 message, the ServerKeyExchange, the ClientKeyExchange, the 217 CertificateRequest, the client's Certificate message, and the 218 CertificateVerify. Next, we describe each ECC key exchange algorithm 219 in greater detail in terms of the content and processing of these 220 messages. For ease of exposition, we defer discussion of client 221 authentication and associated messages (identified with a + in Figure 222 1) until Section 3 and of the optional ECC-specific extensions (which 223 impact the Hello messages) until Section 4. 225 2.1 ECDH_ECDSA 227 In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable 228 public key and be signed with ECDSA. 230 A ServerKeyExchange MUST NOT be sent (the server's certificate 231 contains all the necessary keying information required by the client 232 to arrive at the premaster secret). 234 The client MUST generate an ECDH key pair on the same curve as the 235 server's long-term public key and send its public key in the 236 ClientKeyExchange message (except when using client authentication 237 algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the 238 modifications from section Section 3.2 or Section 3.3 apply). 240 Both client and server MUST perform an ECDH operation and use the 241 resultant shared secret as the premaster secret. All ECDH 242 calculations are performed as specified in Section 5.10 244 2.2 ECDHE_ECDSA 246 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- 247 capable public key and be signed with ECDSA. 249 The server MUST send its ephemeral ECDH public key and a 250 specification of the corresponding curve in the ServerKeyExchange 251 message. These parameters MUST be signed with ECDSA using the 252 private key corresponding to the public key in the server's 253 Certificate. 255 The client MUST generate an ECDH key pair on the same curve as the 256 server's ephemeral ECDH key and send its public key in the 257 ClientKeyExchange message. 259 Both client and server MUST perform an ECDH operation (Section 5.10) 260 and use the resultant shared secret as the premaster secret. 262 2.3 ECDH_RSA 264 This key exchange algorithm is the same as ECDH_ECDSA except the 265 server's certificate MUST be signed with RSA rather than ECDSA. 267 2.4 ECDHE_RSA 269 This key exchange algorithm is the same as ECDHE_ECDSA except the 270 server's certificate MUST contain an RSA public key authorized for 271 signing and the signature in the ServerKeyExchange message MUST be 272 computed with the corresponding RSA private key. The server 273 certificate MUST be signed with RSA. 275 2.5 ECDH_anon 277 In ECDH_anon, the server's Certificate, the CertificateRequest, the 278 client's Certificate, and the CertificateVerify messages MUST NOT be 279 sent. 281 The server MUST send an ephemeral ECDH public key and a specification 282 of the corresponding curve in the ServerKeyExchange message. These 283 parameters MUST NOT be signed. 285 The client MUST generate an ECDH key pair on the same curve as the 286 server's ephemeral ECDH key and send its public key in the 287 ClientKeyExchange message. 289 Both client and server MUST perform an ECDH operation and use the 290 resultant shared secret as the premaster secret. All ECDH 291 calculations are performed as specified in Section 5.10 293 3. Client Authentication 295 This document defines three new client authentication mechanisms 296 named after the type of client certificate involved: ECDSA_sign, 297 ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is 298 usable with any of the non-anonymous ECC key exchange algorithms 299 described in Section 2 as well as other non-anonymous (non-ECC) key 300 exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and 301 RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. 302 Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the 303 use of a long-term ECDH client key would jeopardize the forward 304 secrecy property of these algorithms. 306 The server can request ECC-based client authentication by including 307 one or more of these certificate types in its CertificateRequest 308 message. The server MUST NOT include any certificate types that are 309 prohibited for the negotiated key exchange algorithm. The client 310 must check if it possesses a certificate appropriate for any of the 311 methods suggested by the server and is willing to use it for 312 authentication. 314 If these conditions are not met, the client should send a client 315 Certificate message containing no certificates. In this case, the 316 ClientKeyExchange should be sent as described in Section 2 and the 317 CertificateVerify should not be sent. If the server requires client 318 authentication, it may respond with a fatal handshake failure alert. 320 If the client has an appropriate certificate and is willing to use it 321 for authentication, it MUST send that certificate in the client's 322 Certificate message (as per Section 5.6) and prove possession of the 323 private key corresponding to the certified key. The process of 324 determining an appropriate certificate and proving possession is 325 different for each authentication mechanism and described below. 327 NOTE: It is permissible for a server to request (and the client to 328 send) a client certificate of a different type than the server 329 certificate. 331 3.1 ECDSA_sign 333 To use this authentication mechanism, the client MUST possess a 334 certificate containing an ECDSA-capable public key and signed with 335 ECDSA. 337 The client MUST prove possession of the private key corresponding to 338 the certified key by including a signature in the CertificateVerify 339 message as described in Section 5.8. 341 3.2 ECDSA_fixed_ECDH 343 To use this authentication mechanism, the client MUST possess a 344 certificate containing an ECDH-capable public key and that 345 certificate MUST be signed with ECDSA. Furthermore, the client's 346 ECDH key MUST be on the same elliptic curve as the server's long-term 347 (certified) ECDH key. 349 When using this authentication mechanism, the client MUST send an 350 empty ClientKeyExchange as described in Section 5.7 and MUST NOT send 351 the CertificateVerify message. The ClientKeyExchange is empty since 352 the client's ECDH public key required by the server to compute the 353 premaster secret is available inside the client's certificate. The 354 client's ability to arrive at the same premaster secret as the server 355 (demonstrated by a successful exchange of Finished messages) proves 356 possession of the private key corresponding to the certified public 357 key and the CertificateVerify message is unnecessary. 359 3.3 RSA_fixed_ECDH 361 This authentication mechanism is identical to ECDSA_fixed_ECDH except 362 the client's certificate MUST be signed with RSA. 364 4. TLS Extensions for ECC 366 Two new TLS extensions --- (i) the Supported Elliptic Curves 367 Extension, and (ii) the Supported Point Formats Extension --- allow a 368 client to negotiate the use of specific curves and point formats 369 (e.g. compressed v/s uncompressed), respectively. These extensions 370 are especially relevant for constrained clients that may only support 371 a limited number of curves or point formats. They follow the 372 general approach outlined in [3]. The client enumerates the curves 373 and point formats it supports by including the appropriate extensions 374 in its ClientHello message. By echoing that extension in its 375 ServerHello, the server agrees to restrict its key selection or 376 encoding to the choices specified by the client. 378 A TLS client that proposes ECC cipher suites in its ClientHello 379 message SHOULD include these extensions. Servers implementing ECC 380 cipher suites MUST support these extensions and negotiate the use of 381 an ECC cipher suite only if they can complete the handshake while 382 limiting themselves to the curves and compression techniques 383 enumerated by the client. This eliminates the possibility that a 384 negotiated ECC handshake will be subsequently aborted due to a 385 client's inability to deal with the server's EC key. 387 These extensions MUST NOT be included if the client does not propose 388 any ECC cipher suites. A client that proposes ECC cipher suites may 389 choose not to include these extension. In this case, the server is 390 free to choose any one of the elliptic curves or point formats listed 391 in Section 5. That section also describes the structure and 392 processing of these extensions in greater detail. 394 5. Data Structures and Computations 396 This section specifies the data structures and computations used by 397 ECC-based key mechanisms specified in Section 2, Section 3 and 398 Section 4. The presentation language used here is the same as that 399 used in TLS [2]. Since this specification extends TLS, these 400 descriptions should be merged with those in the TLS specification and 401 any others that extend TLS. This means that enum types may not 402 specify all possible values and structures with multiple formats 403 chosen with a select() clause may not indicate all possible cases. 405 5.1 Client Hello Extensions 407 When this message is sent: 409 The ECC extensions SHOULD be sent along with any ClientHello message 410 that proposes ECC cipher suites. 412 Meaning of this message: 414 These extensions allow a constrained client to enumerate the elliptic 415 curves and/or point formats it supports. 417 Structure of this message: 419 The general structure of TLS extensions is described in [3] and this 420 specification adds two new types to ExtensionType. 422 enum { ellptic_curves(6), ec_point_formats(7) } ExtensionType; 424 elliptic_curves: Indicates the set of elliptic curves supported by 425 the client. For this extension, the opaque extension_data field 426 contains EllipticCurveList. 428 ec_point_formats: Indicates the set of point formats supported by 429 the client. For this extension, the opaque extension_data field 430 contains ECPointFormatList. 432 enum { 433 sect163k1 (1), sect163r1 (2), sect163r2 (3), 434 sect193r1 (4), sect193r2 (5), sect233k1 (6), 435 sect233r1 (7), sect239k1 (8), sect283k1 (9), 436 sect283r1 (10), sect409k1 (11), sect409r1 (12), 437 sect571k1 (13), sect571r1 (14), secp160k1 (15), 438 secp160r1 (16), secp160r2 (17), secp192k1 (18), 439 secp192r1 (19), secp224k1 (20), secp224r1 (21), 440 secp256k1 (22), secp256r1 (23), secp384r1 (24), 441 secp521r1 (25), reserved (240..247), 442 arbitrary_explicit_prime_curves(253), 443 arbitrary_explicit_char2_curves(254), 444 (255) 445 } NamedCurve; 447 sect163k1, etc: Indicates support of the corresponding named curve 448 specified in SEC 2 [10]. Note that many of these curves are also 449 recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 450 through 247 are reserved for private use. Values 253 and 254 451 indicate that the client supports arbitrary prime and 452 charactersitic two curves, respectively (the curve parameters must 453 be encoded explicitly in ECParameters). 455 struct { 456 NamedCurve elliptic_curve_list<1..2^16-1> 457 } EllipticCurveList; 459 As an example, a client that only supports secp192r1 (aka NIST P-192) 460 and secp192r1 (aka NIST P-224) would include an elliptic_curves 461 extension with the following octets: 463 00 06 00 02 13 14 465 A client that supports arbitrary explicit binary polynomial curves 466 would include an extension with the following octets: 468 00 06 00 01 fe 470 enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) } 471 ECPointFormat; 473 struct { 474 ECPointFormat ec_point_format_list<1..2^16-1> 475 } ECPointFormatList; 477 A client that only supports the uncompressed point format includes an 478 extension with the following octets: 480 00 07 00 01 00 482 A client that prefers the use of the ansiX963_compressed format over 483 uncompressed may indicate that preference by including an extension 484 with the following octets: 486 00 07 00 02 01 00 488 Actions of the sender: 490 A client that proposes ECC cipher suites in its ClientHello appends 491 these extensions (along with any others) enumerating the curves and 492 point formats it supports. 494 Actions of the receiver: 496 A server that receives a ClientHello containing one or both of these 497 extensions MUST use the client's enumerated capabilities to guide its 498 selection of an appropriate cipher suite. One of the proposed ECC 499 cipher suites must be negotiated only if the server can successfully 500 complete the handshake while using the curves and point formats 501 supported by the client. 503 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 504 different curves for (i) the ECDSA key in its certificate, and (ii) 505 the ephemeral ECDH key in the ServerKeyExchange message. The server 506 must consider the "elliptic_curves" extension in selecting both of 507 these curves. 509 If a server does not understand the "elliptic_curves" extension or is 510 unable to complete the ECC handshake while restricting itself to the 511 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 512 suite. Depending on what other cipher suites are proposed by the 513 client and supported by the server, this may result in a fatal 514 handshake failure alert due to the lack of common cipher suites. 516 5.2 Server Hello Extensions 518 When this message is sent: 520 The ServerHello ECC extensions are sent in response to a Client Hello 521 message containing ECC extensions when negotiating an ECC cipher 522 suite. 524 Meaning of this message: 526 These extensions indicate the server's agreement to use only the 527 elliptic curves and point formats supported by the client during the 528 ECC-based key exchange. 530 Structure of this message: 532 The ECC extensions echoed by the server are the same as those in the 533 ClientHello except the "extension_data" field is empty. 535 For example, a server indicates its acceptance of the client's 536 elliptic_curves extension by sending an extension with the following 537 octets: 539 00 06 00 00 541 Actions of the sender: 543 A server makes sure that it can complete a proposed ECC key exchange 544 mechanism by restricting itself to the curves/point formats supported 545 by the client before sending these extensions. 547 Actions of the receiver: 549 A client that receives a ServerHello with ECC extensions proceeds 550 with an ECC key exchange assured that it will be able to handle the 551 server's EC key(s). 553 5.3 Server Certificate 555 When this message is sent: 557 This message is sent in all non-anonymous ECC-based key exchange 558 algorithms. 560 Meaning of this message: 562 This message is used to authentically convey the server's static 563 public key to the client. The following table shows the server 564 certificate type appropriate for each key exchange algorithm. ECC 565 public keys must be encoded in certificates as described in Section 566 5.9. 568 NOTE: The server's Certificate message is capable of carrying a chain 569 of certificates. The restrictions mentioned in Table 3 apply only to 570 the server's certificate (first in the chain). 572 Key Exchange Algorithm Server Certificate Type 573 ---------------------- ----------------------- 575 ECDH_ECDSA Certificate must contain an 576 ECDH-capable public key. It 577 must be signed with ECDSA. 579 ECDHE_ECDSA Certificate must contain an 580 ECDSA-capable public key. It 581 must be signed with ECDSA. 583 ECDH_RSA Certificate must contain an 584 ECDH-capable public key. It 585 must be signed with RSA. 587 ECDHE_RSA Certificate must contain an 588 RSA public key authorized for 589 use in digital signatures. It 590 must be signed with RSA. 592 Table 3: Server certificate types 594 Structure of this message: 596 Identical to the TLS Certificate format. 598 Actions of the sender: 600 The server constructs an appropriate certificate chain and conveys it 601 to the client in the Certificate message. 603 Actions of the receiver: 605 The client validates the certificate chain, extracts the server's 606 public key, and checks that the key type is appropriate for the 607 negotiated key exchange algorithm. 609 5.4 Server Key Exchange 611 When this message is sent: 613 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 614 ECDH_anon key exchange algorithms. 616 Meaning of this message: 618 This message is used to convey the server's ephemeral ECDH public key 619 (and the corresponding elliptic curve domain parameters) to the 620 client. 622 Structure of this message: 624 enum { explicit_prime (1), explicit_char2 (2), 625 named_curve (3), (255) } ECCurveType; 627 explicit_prime: Indicates the elliptic curve domain parameters are 628 conveyed verbosely, and the underlying finite field is a prime 629 field. 631 explicit_char2: Indicates the elliptic curve domain parameters are 632 conveyed verbosely, and the underlying finite field is a 633 characteristic 2 field. 635 named_curve: Indicates that a named curve is used. This option 636 SHOULD be used when applicable. 638 struct { 639 opaque a <1..2^8-1>; 640 opaque b <1..2^8-1>; 641 opaque seed <0..2^8-1>; 642 } ECCurve; 644 a, b: These parameters specify the coefficients of the elliptic 645 curve. Each value contains the byte string representation of a 646 field element following the conversion routine in Section 4.3.3 of 647 ANSI X9.62 [6]. 649 seed: This is an optional parameter used to derive the coefficients 650 of a randomly generated elliptic curve. 652 struct { 653 opaque point <1..2^8-1>; 654 } ECPoint; 656 point: This is the byte string representation of an elliptic curve 657 point following the conversion routine in Section 4.3.6 of ANSI 658 X9.62 [6]. Note that this byte string may represent an elliptic 659 curve point in compressed or uncompressed form. Implementations 660 of this specification MUST support the uncompressed form and MAY 661 support the compressed form. 663 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 665 ec_basis_trinomial: Indicates representation of a characteristic two 666 field using a trinomial basis. 668 ec_basis_pentanomial: Indicates representation of a characteristic 669 two field using a pentanomial basis. 671 struct { 672 ECCurveType curve_type; 673 select (curve_type) { 674 case explicit_prime: 675 opaque prime_p <1..2^8-1>; 676 ECCurve curve; 677 ECPoint base; 678 opaque order <1..2^8-1>; 679 opaque cofactor <1..2^8-1>; 680 case explicit_char2: 681 uint16 m; 682 ECBasisType basis; 683 select (basis) { 684 case ec_trinomial: 685 opaque k <1..2^8-1>; 686 case ec_pentanomial: 687 opaque k1 <1..2^8-1>; 688 opaque k2 <1..2^8-1>; 689 opaque k3 <1..2^8-1>; 690 }; 691 ECCurve curve; 692 ECPoint base; 693 opaque order <1..2^8-1>; 694 opaque cofactor <1..2^8-1>; 695 case named_curve: 696 NamedCurve namedcurve; 697 }; 698 } ECParameters; 700 curve_type: This identifies the type of the elliptic curve domain 701 parameters. 703 prime_p: This is the odd prime defining the field Fp. 705 curve: Specifies the coefficients a and b (and optional seed) of the 706 elliptic curve E. 708 base: Specifies the base point G on the elliptic curve. 710 order: Specifies the order n of the base point. 712 cofactor: Specifies the cofactor h = #E(Fq)/n, where #E(Fq) 713 represents the number of points on the elliptic curve E defined 714 over the field Fq. 716 m: This is the degree of the characteristic-two field F2^m. 718 k: The exponent k for the trinomial basis representation x^m + x^k 719 +1. 721 k1, k2, k3: The exponents for the pentanomial representation x^m + 722 x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). 724 namedcurve: Specifies a recommended set of elliptic curve domain 725 parameters. All enum values of NamedCurve are allowed except for 726 arbitrary_explicit_prime_curves(253) and 727 arbitrary_explicit_char2_curves(254). These two values are only 728 allowed in the ClientHello extension. 730 struct { 731 ECParameters curve_params; 732 ECPoint public; 733 } ServerECDHParams; 735 curve_params: Specifies the elliptic curve domain parameters 736 associated with the ECDH public key. 738 public: The ephemeral ECDH public key. 740 The ServerKeyExchange message is extended as follows. 742 enum { ec_diffie_hellman } KeyExchangeAlgorithm; 744 ec_diffie_hellman: Indicates the ServerKeyExchange message contains 745 an ECDH public key. 747 select (KeyExchangeAlgorithm) { 748 case ec_diffie_hellman: 749 ServerECDHParams params; 750 Signature signed_params; 751 } ServerKeyExchange; 753 params: Specifies the ECDH public key and associated domain 754 parameters. 756 signed_params: A hash of the params, with the signature appropriate 757 to that hash applied. The private key corresponding to the 758 certified public key in the server's Certificate message is used 759 for signing. 761 enum { ecdsa } SignatureAlgorithm; 763 select (SignatureAlgorithm) { 764 case ecdsa: 765 digitally-signed struct { 766 opaque sha_hash[sha_size]; 767 }; 768 } Signature; 770 NOTE: SignatureAlgorithm is 'rsa' for the ECDHE_RSA key exchange 771 algorithm and 'anonymous' for ECDH_anon. These cases are defined in 772 TLS [2]. SignatureAlgorithm is 'ecdsa' for ECDHE_ECDSA. ECDSA 773 signatures are generated and verified as described in Section 5.10. 774 As per ANSI X9.62, an ECDSA signature consists of a pair of integers 775 r and s. These integers are both converted into byte strings of the 776 same length as the curve order n using the conversion routine 777 specified in Section 4.3.1 of [6]. The two byte strings are 778 concatenated, and the result is placed in the signature field. 780 Actions of the sender: 782 The server selects elliptic curve domain parameters and an ephemeral 783 ECDH public key corresponding to these parameters according to the 784 ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to 785 the client in the ServerKeyExchange message using the format defined 786 above. 788 Actions of the recipient: 790 The client verifies the signature (when present) and retrieves the 791 server's elliptic curve domain parameters and ephemeral ECDH public 792 key from the ServerKeyExchange message. 794 5.5 Certificate Request 796 When this message is sent: 798 This message is sent when requesting client authentication. 800 Meaning of this message: 802 The server uses this message to suggest acceptable client 803 authentication methods. 805 Structure of this message: 807 The TLS CertificateRequest message is extended as follows. 809 enum { 810 ecdsa_sign(?), rsa_fixed_ecdh(?), 811 ecdsa_fixed_ecdh(?), (255) 812 } ClientCertificateType; 814 ecdsa_sign, etc Indicates that the server would like to use the 815 corresponding client authentication method specified in Section 3. 817 EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and 818 ecdsa_fixed_ecdh have been left as ?. These values will be 819 assigned when this draft progresses to RFC. Earlier versions of 820 this draft used the values 5, 6, and 7 - however these values have 821 been removed since they are used differently by SSL 3.0 [13] and 822 their use by TLS is being deprecated. 824 Actions of the sender: 826 The server decides which client authentication methods it would like 827 to use, and conveys this information to the client using the format 828 defined above. 830 Actions of the receiver: 832 The client determines whether it has an appropriate certificate for 833 use with any of the requested methods, and decides whether or not to 834 proceed with client authentication. 836 5.6 Client Certificate 838 When this message is sent: 840 This message is sent in response to a CertificateRequest when a 841 client has a suitable certificate. 843 Meaning of this message: 845 This message is used to authentically convey the client's static 846 public key to the server. The following table summarizes what client 847 certificate types are appropriate for the ECC-based client 848 authentication mechanisms described in Section 3. ECC public keys 849 must be encoded in certificates as described in Section 5.9. 851 NOTE: The client's Certificate message is capable of carrying a chain 852 of certificates. The restrictions mentioned in Table 4 apply only to 853 the client's certificate (first in the chain). 855 Client 856 Authentication Method Client Certificate Type 857 --------------------- ----------------------- 859 ECDSA_sign Certificate must contain an 860 ECDSA-capable public key and 861 be signed with ECDSA. 863 ECDSA_fixed_ECDH Certificate must contain an 864 ECDH-capable public key on the 865 same elliptic curve as the server's 866 long-term ECDH key. This certificate 867 must be signed with ECDSA. 869 RSA_fixed_ECDH Certificate must contain an 870 ECDH-capable public key on the 871 same elliptic curve as the server's 872 long-term ECDH key. This certificate 873 must be signed with RSA. 875 Table 4: Client certificate types 877 Structure of this message: 879 Identical to the TLS client Certificate format. 881 Actions of the sender: 883 The client constructs an appropriate certificate chain, and conveys 884 it to the server in the Certificate message. 886 Actions of the receiver: 888 The TLS server validates the certificate chain, extracts the client's 889 public key, and checks that the key type is appropriate for the 890 client authentication method. 892 5.7 Client Key Exchange 894 When this message is sent: 896 This message is sent in all key exchange algorithms. If client 897 authentication with ECDSA_fixed_ECDH or RSA_fixed_ECDH is used, this 898 message is empty. Otherwise, it contains the client's ephemeral ECDH 899 public key. 901 Meaning of the message: 903 This message is used to convey ephemeral data relating to the key 904 exchange belonging to the client (such as its ephemeral ECDH public 905 key). 907 Structure of this message: 909 The TLS ClientKeyExchange message is extended as follows. 911 enum { yes, no } EphemeralPublicKey; 913 yes, no: Indicates whether or not the client is providing an 914 ephemeral ECDH public key. (In ECC ciphersuites, this is "yes" 915 except when the client uses the ECDSA_fixed_ECDH or RSA_fixed_ECDH 916 client authentication mechanism.) 918 struct { 919 select (EphemeralPublicKey) { 920 case yes: ECPoint ecdh_Yc; 921 case no: struct { }; 922 } ecdh_public; 923 } ClientECDiffieHellmanPublic; 925 ecdh_Yc: Contains the client's ephemeral ECDH public key. 927 struct { 928 select (KeyExchangeAlgorithm) { 929 case ec_diffie_hellman: ClientECDiffieHellmanPublic; 930 } exchange_keys; 931 } ClientKeyExchange; 933 Actions of the sender: 935 The client selects an ephemeral ECDH public key corresponding to the 936 parameters it received from the server according to the ECKAS-DH1 937 scheme from IEEE 1363 [5]. It conveys this information to the client 938 in the ClientKeyExchange message using the format defined above. 940 Actions of the recipient: 942 The server retrieves the client's ephemeral ECDH public key from the 943 ClientKeyExchange message and checks that it is on the same elliptic 944 curve as the server's ECDH key. 946 5.8 Certificate Verify 948 When this message is sent: 950 This message is sent when the client sends a client certificate 951 containing a public key usable for digital signatures, e.g. when the 952 client is authenticated using the ECDSA_sign mechanism. 954 Meaning of the message: 956 This message contains a signature that proves possession of the 957 private key corresponding to the public key in the client's 958 Certificate message. 960 Structure of this message: 962 The TLS CertificateVerify message is extended as follows. 964 enum { ecdsa } SignatureAlgorithm; 966 select (SignatureAlgorithm) { 967 case ecdsa: 968 digitally-signed struct { 969 opaque sha_hash[sha_size]; 970 }; 971 } Signature; 973 For the ecdsa case, the signature field in the CertificateVerify 974 message contains an ECDSA signature computed over handshake messages 975 exchanged so far. ECDSA signatures are computed as described in 976 Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a 977 pair of integers r and s. These integers are both converted into 978 byte strings of the same length as the curve order n using the 979 conversion routine specified in Section 4.3.1 of [6]. The two byte 980 strings are concatenated, and the result is placed in the signature 981 field. 983 Actions of the sender: 985 The client computes its signature over all handshake messages sent or 986 received starting at client hello up to but not including this 987 message. It uses the private key corresponding to its certified 988 public key to compute the signature which is conveyed in the format 989 defined above. 991 Actions of the receiver: 993 The server extracts the client's signature from the CertificateVerify 994 message, and verifies the signature using the public key it received 995 in the client's Certificate message. 997 5.9 Elliptic Curve Certificates 999 X509 certificates containing ECC public keys or signed using ECDSA 1000 MUST comply with [11]. Clients SHOULD use the elliptic curve domain 1001 parameters recommended in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 1002 [10]. 1004 5.10 ECDH, ECDSA and RSA Computations 1006 All ECDH calculations (including parameter and key generation as well 1007 as the shared secret calculation) MUST be performed according to [5] 1008 using 1010 o the ECKAS-DH1 scheme with the ECSVDP-DH secret value derivation 1011 primitive, the KDF1 key derivation function using SHA-1 [7], and 1012 null key derivation parameters "P" for elliptic curve parameters 1013 where field elements are represented as octet strings of length 24 1014 or less (using the IEEE 1363 FE2OSP); in this case, the premaster 1015 secret is the output of the ECKAS-DH1 scheme, i.e. the 20-byte 1016 SHA-1 output from the KDF. 1018 o the ECKAS-DH1 scheme with the identity map as key derivation 1019 function for elliptic curve parameters where field elements are 1020 represented as octet strings of length more than 24; in this case, 1021 the premaster secret is the x-coordinate of the ECDH shared secret 1022 elliptic curve point, i.e. the octet string Z in IEEE 1363 1023 terminology. 1025 Note that a new extension may be introduced in the future to allow 1026 the use of a different KDF during computation of the premaster 1027 secret. In this event, the new KDF would be used in place of the 1028 process detailed above. This may be desirable, for example, to 1029 support compatibility with the planned NIST key agreement standard. 1031 All ECDSA computations MUST be performed according to ANSI X9.62 [6] 1032 or its successors. Data to be signed/verified is hashed and the 1033 result run directly through the ECDSA algorithm with no additional 1034 hashing. The default hash function is SHA-1 [7] and sha_size (see 1035 Section 5.4 and Section 5.8) is 20. However, an alternative hash 1036 function, such as one of the new SHA hash functions specified in FIPS 1037 180-2 [7], may be used instead if the certificate containing the EC 1038 public key explicitly requires use of another hash function. 1040 All RSA signatures must be generated and verified according to PKCS#1 1041 [9]. 1043 6. Cipher Suites 1045 The table below defines new ECC cipher suites that use the key 1046 exchange algorithms specified in Section 2. 1048 EDITOR: Most of the cipher suites below have been left as ??. The 1049 values 47-4C correspond to cipher suites which are known to have been 1050 implemented and are therefore proposed here. The final determination 1051 of cipher suite numbers will occur when this draft progresses to RFC. 1052 Implementers using the values 47-4C should therefore be wary that 1053 these values may change. 1055 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } 1056 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 1057 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 1058 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 1059 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } 1060 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 1062 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1063 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1064 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1065 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1066 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1068 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1069 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1070 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1071 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1072 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1074 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1075 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1076 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1077 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1078 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1080 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1081 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1082 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1083 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1084 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1086 Table 5: TLS ECC cipher suites 1088 The key exchange method, cipher, and hash algorithm for each of these 1089 cipher suites are easily determined by examining the name. Ciphers 1090 other than AES ciphers, and hash algorithms are defined in [2]. AES 1091 ciphers are defined in [14]. 1093 Server implementations SHOULD support all of the following cipher 1094 suites, and client implementations SHOULD support at least one of 1095 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1096 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1097 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1098 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1100 7. Security Considerations 1102 This document is based on [2], [5], [6] and [14]. The appropriate 1103 security considerations of those documents apply. 1105 For ECDH (Section 5.10), this document specifies two different ways 1106 to compute the premaster secret. The choice of the method is 1107 determined by the elliptic curve. Earlier versions of this 1108 specification used the KDF1 key derivation function with SHA-1 in all 1109 cases; the current version keeps this key derivation function only 1110 for curves where field elements are represented as octet strings of 1111 length 24 or less (i.e. up to 192 bits), but omits it for larger 1112 curves. 1114 Rationale: Using KDF1 with SHA-1 limits the security to at most 160 1115 bits, independently of the elliptic curve used for ECDH. For large 1116 curves, this would result in worse security than expected. Using a 1117 specific key derivation function for ECDH is not really necessary as 1118 TLS always uses its PRF to derive the master secret from the 1119 premaster secret. For large curves, the current specification 1120 handles ECDH like the basic TLS specification [14] handles standard 1121 DH. For smaller curves where the extra KDF1 step does not weaken 1122 security, the current specification keeps the KDF1 step to obtain 1123 compatibility with existing implementations of earlier versions of 1124 this specification. Note that the threshold for switching between 1125 the two ECDH calculation methods is necessarily somewhat arbitrary; 1126 192-bit ECC corresponds to approximately 96 bits of security in the 1127 light of square root attacks, so the 160 bits provided by SHA-1 are 1128 comfortable at this limit. 1130 8. Intellectual Property Rights 1132 The IETF has been notified of intellectual property rights claimed in 1133 regard to the specification contained in this document. For more 1134 information, consult the online list of claimed rights (http:// 1135 www.ietf.org/ipr.html). 1137 The IETF takes no position regarding the validity or scope of any 1138 intellectual property or other rights that might be claimed to 1139 pertain to the implementation or use of the technology described in 1140 this document or the extent to which any license under such rights 1141 might or might not be available; neither does it represent that it 1142 has made any effort to identify any such rights. Information on the 1143 IETF's procedures with respect to rights in standards-track and 1144 standards-related documentation can be found in [15]. Copies of 1145 claims of rights made available for publication and any assurances of 1146 licenses to be made available, or the result of an attempt made to 1147 obtain a general license or permission for the use of such 1148 proprietary rights by implementers or users of this specification can 1149 be obtained from the IETF Secretariat. 1151 9. Acknowledgments 1153 The authors wish to thank Bill Anderson and Tim Dierks. 1155 Normative References 1157 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1158 Levels", RFC 2119, March 1997. 1160 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1161 2246, January 1999. 1163 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 1164 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 1165 3546, June 2003. 1167 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . 1170 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1171 IEEE 1363, 2000. 1173 [6] ANSI, "Public Key Cryptography For The Financial Services 1174 Industry: The Elliptic Curve Digital Signature Algorithm 1175 (ECDSA)", ANSI X9.62, 1998. 1177 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1179 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1181 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1182 1.5", PKCS 1, November 1993. 1184 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1185 2000, . 1187 [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1188 Identifiers for the Internet X.509 Public Key Infrastructure 1189 Certificate and Certificate Revocation List (CRL) Profile", RFC 1190 3279, April 2002. 1192 Informative References 1194 [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1195 Sizes", Journal of Cryptology 14 (2001) 255-293, . 1198 [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 1199 Version 3.0", November 1996, . 1202 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1203 Transport Layer Security (TLS)", RFC 3268, June 2002. 1205 [15] Hovey, R. and S. Bradner, "The Organizations Involved in the 1206 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1208 Authors' Addresses 1210 Vipul Gupta 1211 Sun Microsystems Laboratories 1212 2600 Casey Avenue 1213 MS UMTV29-235 1214 Mountain View, CA 94303 1215 USA 1217 Phone: +1 650 336 1681 1218 EMail: vipul.gupta@sun.com 1220 Simon Blake-Wilson 1221 Basic Commerce & Industries, Inc. 1222 96 Spandia Ave 1223 Unit 606 1224 Toronto, ON M6G 2T6 1225 Canada 1227 Phone: +1 416 214 5961 1228 EMail: sblakewilson@bcisse.com 1230 Bodo Moeller 1231 TBD 1233 EMail: moeller@cdc.informatik.tu-darmstadt.de 1234 Chris Hawk 1235 Independent Consultant 1237 EMail: chris@socialeng.com 1239 Nelson Bolyard 1240 Netscape 1242 EMail: misterssl@aol.com 1244 Full Copyright Statement 1246 Copyright (C) The Internet Society (2003). All Rights Reserved. 1248 This document and translations of it may be copied and furnished to 1249 others, and derivative works that comment on or otherwise explain it 1250 or assist in its implementation may be prepared, copied, published 1251 and distributed, in whole or in part, without restriction of any 1252 kind, provided that the above copyright notice and this paragraph are 1253 included on all such copies and derivative works. However, this 1254 document itself may not be modified in any way, such as by removing 1255 the copyright notice or references to the Internet Society or other 1256 Internet organizations, except as needed for the purpose of 1257 developing Internet standards in which case the procedures for 1258 copyrights defined in the Internet Standards process must be 1259 followed, or as required to translate it into languages other than 1260 English. 1262 The limited permissions granted above are perpetual and will not be 1263 revoked by the Internet Society or its successors or assigns. 1265 This document and the information contained herein is provided on an 1266 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1267 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1268 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1269 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1270 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1272 Acknowledgement 1274 Funding for the RFC Editor function is currently provided by the 1275 Internet Society.