idnits 2.17.00 (12 Aug 2021) /tmp/idnits11694/draft-ietf-tls-ecc-05.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 673 has weird spacing: '...rveType cur...' == Line 686 has weird spacing: '... opaque k <1....' == Line 688 has weird spacing: '... opaque k1 <1...' == Line 689 has weird spacing: '... opaque k2 <1...' == Line 690 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 1210, 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: July 1, 2004 S. Blake-Wilson 4 BCI 5 B. Moeller 6 University of California, Berkeley 7 C. Hawk 8 Independent Consultant 9 N. Bolyard 10 Netscape 11 Jan. 2004 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 July 1, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . . . 15 75 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . . 15 76 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . . 17 77 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . . 21 78 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . . 21 79 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . . 23 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 Items in elliptic_curve_list are ordered according to the client's 460 preferences (favorite choice first). 462 As an example, a client that only supports secp192r1 (aka NIST P-192) 463 and secp224r1 (aka NIST P-224) and prefers to use secp192r1, would 464 include an elliptic_curves extension with the following octets: 466 00 06 00 02 13 15 468 A client that supports arbitrary explicit binary polynomial curves 469 would include an extension with the following octets: 471 00 06 00 01 fe 472 enum { uncompressed (0), ansiX963_compressed (1), ansiX963_hybrid (2) } 473 ECPointFormat; 475 struct { 476 ECPointFormat ec_point_format_list<1..2^16-1> 477 } ECPointFormatList; 479 Items in ec_point_format_list are ordered according to the client's 480 preferences (favorite choice first). 482 A client that only supports the uncompressed point format includes an 483 extension with the following octets: 485 00 07 00 01 00 487 A client that prefers the use of the ansiX963_compressed format over 488 uncompressed may indicate that preference by including an extension 489 with the following octets: 491 00 07 00 02 01 00 493 Actions of the sender: 495 A client that proposes ECC cipher suites in its ClientHello appends 496 these extensions (along with any others) enumerating the curves and 497 point formats it supports. 499 Actions of the receiver: 501 A server that receives a ClientHello containing one or both of these 502 extensions MUST use the client's enumerated capabilities to guide its 503 selection of an appropriate cipher suite. One of the proposed ECC 504 cipher suites must be negotiated only if the server can successfully 505 complete the handshake while using the curves and point formats 506 supported by the client. 508 NOTE: A server participating in an ECDHE-ECDSA key exchange may use 509 different curves for (i) the ECDSA key in its certificate, and (ii) 510 the ephemeral ECDH key in the ServerKeyExchange message. The server 511 must consider the "elliptic_curves" extension in selecting both of 512 these curves. 514 If a server does not understand the "elliptic_curves" extension or is 515 unable to complete the ECC handshake while restricting itself to the 516 enumerated curves, it MUST NOT negotiate the use of an ECC cipher 517 suite. Depending on what other cipher suites are proposed by the 518 client and supported by the server, this may result in a fatal 519 handshake failure alert due to the lack of common cipher suites. 521 5.2 Server Hello Extensions 523 When this message is sent: 525 The ServerHello ECC extensions are sent in response to a Client Hello 526 message containing ECC extensions when negotiating an ECC cipher 527 suite. 529 Meaning of this message: 531 These extensions indicate the server's agreement to use only the 532 elliptic curves and point formats supported by the client during the 533 ECC-based key exchange. 535 Structure of this message: 537 The ECC extensions echoed by the server are the same as those in the 538 ClientHello except the "extension_data" field is empty. 540 For example, a server indicates its acceptance of the client's 541 elliptic_curves extension by sending an extension with the following 542 octets: 544 00 06 00 00 546 Actions of the sender: 548 A server makes sure that it can complete a proposed ECC key exchange 549 mechanism by restricting itself to the curves/point formats supported 550 by the client before sending these extensions. 552 Actions of the receiver: 554 A client that receives a ServerHello with ECC extensions proceeds 555 with an ECC key exchange assured that it will be able to handle the 556 server's EC key(s). 558 5.3 Server Certificate 560 When this message is sent: 562 This message is sent in all non-anonymous ECC-based key exchange 563 algorithms. 565 Meaning of this message: 567 This message is used to authentically convey the server's static 568 public key to the client. The following table shows the server 569 certificate type appropriate for each key exchange algorithm. ECC 570 public keys must be encoded in certificates as described in Section 571 5.9. 573 NOTE: The server's Certificate message is capable of carrying a chain 574 of certificates. The restrictions mentioned in Table 3 apply only to 575 the server's certificate (first in the chain). 577 Key Exchange Algorithm Server Certificate Type 578 ---------------------- ----------------------- 580 ECDH_ECDSA Certificate must contain an 581 ECDH-capable public key. It 582 must be signed with ECDSA. 584 ECDHE_ECDSA Certificate must contain an 585 ECDSA-capable public key. It 586 must be signed with ECDSA. 588 ECDH_RSA Certificate must contain an 589 ECDH-capable public key. It 590 must be signed with RSA. 592 ECDHE_RSA Certificate must contain an 593 RSA public key authorized for 594 use in digital signatures. It 595 must be signed with RSA. 597 Table 3: Server certificate types 599 Structure of this message: 601 Identical to the TLS Certificate format. 603 Actions of the sender: 605 The server constructs an appropriate certificate chain and conveys it 606 to the client in the Certificate message. 608 Actions of the receiver: 610 The client validates the certificate chain, extracts the server's 611 public key, and checks that the key type is appropriate for the 612 negotiated key exchange algorithm. 614 5.4 Server Key Exchange 616 When this message is sent: 618 This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and 619 ECDH_anon key exchange algorithms. 621 Meaning of this message: 623 This message is used to convey the server's ephemeral ECDH public key 624 (and the corresponding elliptic curve domain parameters) to the 625 client. 627 Structure of this message: 629 enum { explicit_prime (1), explicit_char2 (2), 630 named_curve (3), (255) } ECCurveType; 632 explicit_prime: Indicates the elliptic curve domain parameters are 633 conveyed verbosely, and the underlying finite field is a prime 634 field. 636 explicit_char2: Indicates the elliptic curve domain parameters are 637 conveyed verbosely, and the underlying finite field is a 638 characteristic 2 field. 640 named_curve: Indicates that a named curve is used. This option 641 SHOULD be used when applicable. 643 struct { 644 opaque a <1..2^8-1>; 645 opaque b <1..2^8-1>; 646 } ECCurve; 648 a, b: These parameters specify the coefficients of the elliptic 649 curve. Each value contains the byte string representation of a 650 field element following the conversion routine in Section 4.3.3 of 651 ANSI X9.62 [6]. 653 struct { 654 opaque point <1..2^8-1>; 655 } ECPoint; 657 point: This is the byte string representation of an elliptic curve 658 point following the conversion routine in Section 4.3.6 of ANSI 659 X9.62 [6]. Note that this byte string may represent an elliptic 660 curve point in compressed or uncompressed form. Implementations 661 of this specification MUST support the uncompressed form and MAY 662 support the compressed form. 664 enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; 666 ec_basis_trinomial: Indicates representation of a characteristic two 667 field using a trinomial basis. 669 ec_basis_pentanomial: Indicates representation of a characteristic 670 two field using a pentanomial basis. 672 struct { 673 ECCurveType curve_type; 674 select (curve_type) { 675 case explicit_prime: 676 opaque prime_p <1..2^8-1>; 677 ECCurve curve; 678 ECPoint base; 679 opaque order <1..2^8-1>; 680 opaque cofactor <1..2^8-1>; 681 case explicit_char2: 682 uint16 m; 683 ECBasisType basis; 684 select (basis) { 685 case ec_trinomial: 686 opaque k <1..2^8-1>; 687 case ec_pentanomial: 688 opaque k1 <1..2^8-1>; 689 opaque k2 <1..2^8-1>; 690 opaque k3 <1..2^8-1>; 691 }; 692 ECCurve curve; 693 ECPoint base; 694 opaque order <1..2^8-1>; 695 opaque cofactor <1..2^8-1>; 696 case named_curve: 697 NamedCurve namedcurve; 698 }; 699 } ECParameters; 701 curve_type: This identifies the type of the elliptic curve domain 702 parameters. 704 prime_p: This is the odd prime defining the field Fp. 706 curve: Specifies the coefficients a and b of the 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] or another RFC that replaces or extends it. 1001 Clients SHOULD use the elliptic curve domain parameters recommended 1002 in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [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. (The 1039 mechanism for specifying the required hash function has not been 1040 standardized but this provision anticipates such standardization and 1041 obviates the need to update this document in response. Future PKIX 1042 RFCs may choose, for example, to specify the hash function to be used 1043 with a public key in the parameters field of subjectPublicKeyInfo.) 1045 All RSA signatures must be generated and verified according to PKCS#1 1046 [9]. 1048 6. Cipher Suites 1050 The table below defines new ECC cipher suites that use the key 1051 exchange algorithms specified in Section 2. 1053 EDITOR: Most of the cipher suites below have been left as ??. The 1054 values 47-4C correspond to cipher suites which are known to have been 1055 implemented and are therefore proposed here. The final determination 1056 of cipher suite numbers will occur when this draft progresses to RFC. 1057 Implementers using the values 47-4C should therefore be wary that 1058 these values may change. 1060 CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x47 } 1061 CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x48 } 1062 CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x49 } 1063 CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x4A } 1064 CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x4B } 1065 CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x4C } 1067 CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } 1068 CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1069 CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1070 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1071 CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1073 CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1074 CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1075 CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1076 CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1077 CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1079 CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } 1080 CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } 1081 CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1082 CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1083 CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1085 CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } 1086 CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } 1087 CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } 1088 CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } 1089 CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } 1091 Table 5: TLS ECC cipher suites 1093 The key exchange method, cipher, and hash algorithm for each of these 1094 cipher suites are easily determined by examining the name. Ciphers 1095 other than AES ciphers, and hash algorithms are defined in [2]. AES 1096 ciphers are defined in [14]. 1098 Server implementations SHOULD support all of the following cipher 1099 suites, and client implementations SHOULD support at least one of 1100 them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, 1101 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, 1102 TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and 1103 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. 1105 7. Security Considerations 1107 This document is based on [2], [5], [6] and [14]. The appropriate 1108 security considerations of those documents apply. 1110 For ECDH (Section 5.10), this document specifies two different ways 1111 to compute the premaster secret. The choice of the method is 1112 determined by the elliptic curve. Earlier versions of this 1113 specification used the KDF1 key derivation function with SHA-1 in all 1114 cases; the current version keeps this key derivation function only 1115 for curves where field elements are represented as octet strings of 1116 length 24 or less (i.e. up to 192 bits), but omits it for larger 1117 curves. 1119 Rationale: Using KDF1 with SHA-1 limits the security to at most 160 1120 bits, independently of the elliptic curve used for ECDH. For large 1121 curves, this would result in worse security than expected. Using a 1122 specific key derivation function for ECDH is not really necessary as 1123 TLS always uses its PRF to derive the master secret from the 1124 premaster secret. For large curves, the current specification 1125 handles ECDH like the basic TLS specification [14] handles standard 1126 DH. For smaller curves where the extra KDF1 step does not weaken 1127 security, the current specification keeps the KDF1 step to obtain 1128 compatibility with existing implementations of earlier versions of 1129 this specification. Note that the threshold for switching between 1130 the two ECDH calculation methods is necessarily somewhat arbitrary; 1131 192-bit ECC corresponds to approximately 96 bits of security in the 1132 light of square root attacks, so the 160 bits provided by SHA-1 are 1133 comfortable at this limit. 1135 8. Intellectual Property Rights 1137 The IETF has been notified of intellectual property rights claimed in 1138 regard to the specification contained in this document. For more 1139 information, consult the online list of claimed rights (http:// 1140 www.ietf.org/ipr.html). 1142 The IETF takes no position regarding the validity or scope of any 1143 intellectual property or other rights that might be claimed to 1144 pertain to the implementation or use of the technology described in 1145 this document or the extent to which any license under such rights 1146 might or might not be available; neither does it represent that it 1147 has made any effort to identify any such rights. Information on the 1148 IETF's procedures with respect to rights in standards-track and 1149 standards-related documentation can be found in [15]. Copies of 1150 claims of rights made available for publication and any assurances of 1151 licenses to be made available, or the result of an attempt made to 1152 obtain a general license or permission for the use of such 1153 proprietary rights by implementers or users of this specification can 1154 be obtained from the IETF Secretariat. 1156 9. Acknowledgments 1158 The authors wish to thank Bill Anderson and Tim Dierks. 1160 Normative References 1162 [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement 1163 Levels", RFC 2119, March 1997. 1165 [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 1166 2246, January 1999. 1168 [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J. and 1169 T. Wright, "Transport Layer Security (TLS) Extensions", RFC 1170 3546, June 2003. 1172 [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, . 1175 [5] IEEE, "Standard Specifications for Public Key Cryptography", 1176 IEEE 1363, 2000. 1178 [6] ANSI, "Public Key Cryptography For The Financial Services 1179 Industry: The Elliptic Curve Digital Signature Algorithm 1180 (ECDSA)", ANSI X9.62, 1998. 1182 [7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. 1184 [8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1186 [9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version 1187 1.5", PKCS 1, November 1993. 1189 [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, 1190 2000, . 1192 [11] Polk, T., Housley, R. and L. Bassham, "Algorithms and 1193 Identifiers for the Internet X.509 Public Key Infrastructure 1194 Certificate and Certificate Revocation List (CRL) Profile", RFC 1195 3279, April 2002. 1197 Informative References 1199 [12] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key 1200 Sizes", Journal of Cryptology 14 (2001) 255-293, . 1203 [13] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol 1204 Version 3.0", November 1996, . 1207 [14] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for 1208 Transport Layer Security (TLS)", RFC 3268, June 2002. 1210 [15] Hovey, R. and S. Bradner, "The Organizations Involved in the 1211 IETF Standards Process", RFC 2028, BCP 11, October 1996. 1213 Authors' Addresses 1215 Vipul Gupta 1216 Sun Microsystems Laboratories 1217 2600 Casey Avenue 1218 MS UMTV29-235 1219 Mountain View, CA 94303 1220 USA 1222 Phone: +1 650 336 1681 1223 EMail: vipul.gupta@sun.com 1225 Simon Blake-Wilson 1226 Basic Commerce & Industries, Inc. 1227 96 Spandia Ave 1228 Unit 606 1229 Toronto, ON M6G 2T6 1230 Canada 1232 Phone: +1 416 214 5961 1233 EMail: sblakewilson@bcisse.com 1234 Bodo Moeller 1235 University of California, Berkeley 1236 EECS -- Computer Science Division 1237 513 Soda Hall 1238 Berkeley, CA 94720-1776 1239 USA 1241 EMail: bodo@openssl.org 1243 Chris Hawk 1244 Independent Consultant 1246 EMail: chris@socialeng.com 1248 Nelson Bolyard 1249 Netscape 1251 EMail: misterssl@aol.com 1253 Full Copyright Statement 1255 Copyright (C) The Internet Society (2004). All Rights Reserved. 1257 This document and translations of it may be copied and furnished to 1258 others, and derivative works that comment on or otherwise explain it 1259 or assist in its implementation may be prepared, copied, published 1260 and distributed, in whole or in part, without restriction of any 1261 kind, provided that the above copyright notice and this paragraph are 1262 included on all such copies and derivative works. However, this 1263 document itself may not be modified in any way, such as by removing 1264 the copyright notice or references to the Internet Society or other 1265 Internet organizations, except as needed for the purpose of 1266 developing Internet standards in which case the procedures for 1267 copyrights defined in the Internet Standards process must be 1268 followed, or as required to translate it into languages other than 1269 English. 1271 The limited permissions granted above are perpetual and will not be 1272 revoked by the Internet Society or its successors or assigns. 1274 This document and the information contained herein is provided on an 1275 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1276 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1277 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1278 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1279 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1281 Acknowledgement 1283 Funding for the RFC Editor function is currently provided by the 1284 Internet Society.