< draft-ietf-tls-ecc-10.txt   draft-ietf-tls-ecc-11.txt >
TLS Working Group V. Gupta TLS Working Group V. Gupta
Internet-Draft Sun Labs Internet-Draft Sun Labs
Expires: December 2, 2005 S. Blake-Wilson Expires: March 20, 2006 S. Blake-Wilson
BCI BCI
B. Moeller B. Moeller
University of Calgary University of Calgary
C. Hawk C. Hawk
Corriente Networks Corriente Networks
N. Bolyard N. Bolyard
May 31, 2005 September 16, 2005
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-10.txt> <draft-ietf-tls-ecc-11.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2005. This Internet-Draft will expire on March 20, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document describes new key exchange algorithms based on Elliptic This document describes new key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the TLS (Transport Layer Security) Curve Cryptography (ECC) for the TLS (Transport Layer Security)
protocol. In particular, it specifies the use of Elliptic Curve protocol. In particular, it specifies the use of Elliptic Curve
skipping to change at page 2, line 42 skipping to change at page 2, line 42
5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16
5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18
5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22
5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23
5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24
5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25
5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26
5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 31 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32
9.1 Normative References . . . . . . . . . . . . . . . . . . . 32 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2 Informative References . . . . . . . . . . . . . . . . . . 32 10.1 Normative References . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33 10.2 Informative References . . . . . . . . . . . . . . . . . 33
Intellectual Property and Copyright Statements . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
Intellectual Property and Copyright Statements . . . . . . . 36
1. Introduction 1. Introduction
Elliptic Curve Cryptography (ECC) is emerging as an attractive Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem for mobile/wireless environments. Compared public-key cryptosystem for mobile/wireless environments. Compared
to currently prevalent cryptosystems such as RSA, ECC offers to currently prevalent cryptosystems such as RSA, ECC offers
equivalent security with smaller key sizes. This is illustrated in equivalent security with smaller key sizes. This is illustrated in
the following table, based on [13], which gives approximate the following table, based on [14], which gives approximate
comparable key sizes for symmetric- and asymmetric-key cryptosystems comparable key sizes for symmetric- and asymmetric-key cryptosystems
based on the best-known algorithms for attacking them. based on the best-known algorithms for attacking them.
Symmetric | ECC | DH/DSA/RSA Symmetric | ECC | DH/DSA/RSA
-------------+---------+------------ -------------+---------+------------
80 | 163 | 1024 80 | 163 | 1024
112 | 233 | 2048 112 | 233 | 2048
128 | 283 | 3072 128 | 283 | 3072
192 | 409 | 7680 192 | 409 | 7680
256 | 571 | 15360 256 | 571 | 15360
skipping to change at page 3, line 48 skipping to change at page 3, line 48
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
provides an overview of ECC-based key exchange algorithms for TLS. provides an overview of ECC-based key exchange algorithms for TLS.
Section 3 describes the use of ECC certificates for client Section 3 describes the use of ECC certificates for client
authentication. TLS extensions that allow a client to negotiate the authentication. TLS extensions that allow a client to negotiate the
use of specific curves and point formats are presented in Section 4. use of specific curves and point formats are presented in Section 4.
Section 5 specifies various data structures needed for an ECC-based Section 5 specifies various data structures needed for an ECC-based
handshake, their encoding in TLS messages and the processing of those handshake, their encoding in TLS messages and the processing of those
messages. Section 6 defines new ECC-based cipher suites and messages. Section 6 defines new ECC-based cipher suites and
identifies a small subset of these as recommended for all identifies a small subset of these as recommended for all
implementations of this specification. Section 7 and Section 8 implementations of this specification. Section 7 discusses security
mention security considerations and acknowledgments, respectively. considerations. Section 8 describes IANA considerations for the name
This is followed by a list of references cited in this document, the spaces created by this document. Section 9 gives acknowledgments.
authors' contact information, and statements on intellectual property This is followed by the lists of normative and informative references
rights and copyrights. cited in this document, the authors' contact information, and
statements on intellectual property rights and copyrights.
Implementation of this specification requires familiarity with TLS Implementation of this specification requires familiarity with TLS
[2], TLS extensions [3] and ECC [4][5][6][8]. [2], TLS extensions [3] and ECC [4][5][6][8].
2. Key Exchange Algorithms 2. Key Exchange Algorithms
This document introduces five new ECC-based key exchange algorithms This document introduces five new ECC-based key exchange algorithms
for TLS. All of them use ECDH to compute the TLS premaster secret for TLS. All of them use ECDH to compute the TLS premaster secret
and differ only in the lifetime of ECDH keys (long-term or ephemeral) and differ only in the lifetime of ECDH keys (long-term or ephemeral)
and the mechanism (if any) used to authenticate them. The derivation and the mechanism (if any) used to authenticate them. The derivation
skipping to change at page 7, line 20 skipping to change at page 7, line 20
public key and be signed with ECDSA. public key and be signed with ECDSA.
A ServerKeyExchange MUST NOT be sent (the server's certificate A ServerKeyExchange MUST NOT be sent (the server's certificate
contains all the necessary keying information required by the client contains all the necessary keying information required by the client
to arrive at the premaster secret). to arrive at the premaster secret).
The client generates an ECDH key pair on the same curve as the The client generates an ECDH key pair on the same curve as the
server's long-term public key and send its public key in the server's long-term public key and send its public key in the
ClientKeyExchange message (except when using client authentication ClientKeyExchange message (except when using client authentication
algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the algorithm ECDSA_fixed_ECDH or RSA_fixed_ECDH, in which case the
modifications from section Section 3.2 or Section 3.3 apply). modifications from Section 3.2 or Section 3.3 apply).
Both client and server perform an ECDH operation and use the Both client and server perform an ECDH operation and use the
resultant shared secret as the premaster secret. All ECDH resultant shared secret as the premaster secret. All ECDH
calculations are performed as specified in Section 5.10 calculations are performed as specified in Section 5.10
2.2 ECDHE_ECDSA 2.2 ECDHE_ECDSA
In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-
capable public key and be signed with ECDSA. capable public key and be signed with ECDSA.
skipping to change at page 13, line 19 skipping to change at page 13, line 19
enum { enum {
sect163k1 (1), sect163r1 (2), sect163r2 (3), sect163k1 (1), sect163r1 (2), sect163r2 (3),
sect193r1 (4), sect193r2 (5), sect233k1 (6), sect193r1 (4), sect193r2 (5), sect233k1 (6),
sect233r1 (7), sect239k1 (8), sect283k1 (9), sect233r1 (7), sect239k1 (8), sect283k1 (9),
sect283r1 (10), sect409k1 (11), sect409r1 (12), sect283r1 (10), sect409k1 (11), sect409r1 (12),
sect571k1 (13), sect571r1 (14), secp160k1 (15), sect571k1 (13), sect571r1 (14), secp160k1 (15),
secp160r1 (16), secp160r2 (17), secp192k1 (18), secp160r1 (16), secp160r2 (17), secp192k1 (18),
secp192r1 (19), secp224k1 (20), secp224r1 (21), secp192r1 (19), secp224k1 (20), secp224r1 (21),
secp256k1 (22), secp256r1 (23), secp384r1 (24), secp256k1 (22), secp256r1 (23), secp384r1 (24),
secp521r1 (25), reserved (240..247), secp521r1 (25),
arbitrary_explicit_prime_curves(253), reserved (0xFE00..0xFEFF),
arbitrary_explicit_char2_curves(254), arbitrary_explicit_prime_curves(0xFF01),
(255) arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF)
} NamedCurve; } NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve sect163k1, etc: Indicates support of the corresponding named curve
specified in SEC 2 [10]. Note that many of these curves are also or class of explicitly defined curves. The named curves defined
recommended in ANSI X9.62 [6], and FIPS 186-2 [8]. Values 240 here are those specified in SEC 2 [10]. Note that many of these
through 247 are reserved for private use. Values 253 and 254 curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8].
indicate that the client supports arbitrary prime and Values 0xFE00 through 0xFEFF are reserved for private use. Values
characteristic-2 curves, respectively (the curve parameters must 0xFF01 and 0xFF02 indicate that the client supports arbitrary
be encoded explicitly in ECParameters). prime and characteristic-2 curves, respectively (the curve
parameters must be encoded explicitly in ECParameters).
The NamedCurve name space is maintained by IANA. See Section 8 for
information on how new value assignments are added.
struct { struct {
NamedCurve elliptic_curve_list<1..2^8-1> NamedCurve elliptic_curve_list<1..2^8-1>
} EllipticCurveList; } EllipticCurveList;
Items in elliptic_curve_list are ordered according to the client's Items in elliptic_curve_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
As an example, a client that only supports secp192r1 (aka NIST P-192; As an example, a client that only supports secp192r1 (aka NIST P-192;
value 19 = 0x13) and secp224r1 (aka NIST P-224; value 21 = 0x15) and value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
prefers to use secp192r1 would include a TLS extension consisting of and prefers to use secp192r1 would include a TLS extension consisting
the following octets: of the following octets:
00 ?? 00 03 02 13 15 00 ?? 00 06 00 04 00 13 00 15
A client that supports arbitrary explicit characteristic-2 curves A client that supports arbitrary explicit characteristic-2 curves
(value 254 = 0xFE) would include an extension consisting of the (value 0xFF02) would include an extension consisting of the following
following octets: octets:
00 ?? 00 02 01 FE 00 ?? 00 04 00 02 FF 02
enum { uncompressed (0), ansiX962_compressed_prime (1), enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (3 .. 255) ansiX962_compressed_char2 (2), reserved (248..255)
} ECPointFormat; } ECPointFormat;
struct { struct {
ECPointFormat ec_point_format_list<1..2^8-1> ECPointFormat ec_point_format_list<1..2^8-1>
} ECPointFormatList; } ECPointFormatList;
Three point formats are included in the definition of ECPointFormat Three point formats are included in the definition of ECPointFormat
above. The uncompressed point format is the default format in that above. The uncompressed point format is the default format in that
implementations of this document MUST support it for all of their implementations of this document MUST support it for all of their
supported curves. Compressed point formats reduce bandwidth by supported curves. Compressed point formats reduce bandwidth by
including only the x-coordinate and a single bit of the y-coordinate including only the x-coordinate and a single bit of the y-coordinate
of the point. Implementations of this document MAY support the of the point. Implementations of this document MAY support the
ansiX962_compressed_prime and ansiX962_compressed_char2 formats, ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
where the former applies only to prime curves and the latter applies where the former applies only to prime curves and the latter applies
only to characteristic-2 curves. (All formats are described in [6].) only to characteristic-2 curves. (These formats are specified in
Values 248 through 255 are reserved for private use. [6].) Values 248 through 255 are reserved for private use.
The ECPointFormat name space is maintained by IANA. See Section 8
for information on how new value assignments are added.
Items in ec_point_format_list are ordered according to the client's Items in ec_point_format_list are ordered according to the client's
preferences (favorite choice first). preferences (favorite choice first).
A client that can parse only the uncompressed point format (value 0) A client that can parse only the uncompressed point format (value 0)
includes an extension consisting of the following octets: includes an extension consisting of the following octets:
00 ?? 00 02 01 00 00 ?? 00 02 01 00
A client that in the case of prime fields prefers the compressed A client that in the case of prime fields prefers the compressed
skipping to change at page 18, line 21 skipping to change at page 18, line 25
Meaning of this message: Meaning of this message:
This message is used to convey the server's ephemeral ECDH public key This message is used to convey the server's ephemeral ECDH public key
(and the corresponding elliptic curve domain parameters) to the (and the corresponding elliptic curve domain parameters) to the
client. client.
Structure of this message: Structure of this message:
enum { explicit_prime (1), explicit_char2 (2), enum { explicit_prime (1), explicit_char2 (2),
named_curve (3), reserved(4 .. 255) } ECCurveType; named_curve (3), reserved(248..255) } ECCurveType;
explicit_prime: Indicates the elliptic curve domain parameters are explicit_prime: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a prime conveyed verbosely, and the underlying finite field is a prime
field. field.
explicit_char2: Indicates the elliptic curve domain parameters are explicit_char2: Indicates the elliptic curve domain parameters are
conveyed verbosely, and the underlying finite field is a conveyed verbosely, and the underlying finite field is a
characteristic-2 field. characteristic-2 field.
named_curve: Indicates that a named curve is used. This option named_curve: Indicates that a named curve is used. This option
SHOULD be used when applicable. SHOULD be used when applicable.
Values 248 through 255 are reserved for private use. Values 248 through 255 are reserved for private use.
The ECCurveType name space is maintained by IANA. See Section 8 for
information on how new value assignments are added.
struct { struct {
opaque a <1..2^8-1>; opaque a <1..2^8-1>;
opaque b <1..2^8-1>; opaque b <1..2^8-1>;
} ECCurve; } ECCurve;
a, b: These parameters specify the coefficients of the elliptic a, b: These parameters specify the coefficients of the elliptic
curve. Each value contains the byte string representation of a curve. Each value contains the byte string representation of a
field element following the conversion routine in Section 4.3.3 of field element following the conversion routine in Section 4.3.3 of
ANSI X9.62 [6]. ANSI X9.62 [6].
skipping to change at page 20, line 29 skipping to change at page 20, line 31
m: This is the degree of the characteristic-2 field F2^m. m: This is the degree of the characteristic-2 field F2^m.
k: The exponent k for the trinomial basis representation x^m + x^k k: The exponent k for the trinomial basis representation x^m + x^k
+1. +1.
k1, k2, k3: The exponents for the pentanomial representation x^m + k1, k2, k3: The exponents for the pentanomial representation x^m +
x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1). x^k3 + x^k2 + x^k1 + 1 (such that k3 > k2 > k1).
namedcurve: Specifies a recommended set of elliptic curve domain namedcurve: Specifies a recommended set of elliptic curve domain
parameters. All enum values of NamedCurve are allowed except for parameters. All those values of NamedCurve are allowed that refer
arbitrary_explicit_prime_curves(253) and to a specific curve. Values of NamedCurve that indicate support
arbitrary_explicit_char2_curves(254). These two values are only for a class of explicitly defined curves are not allowed here
allowed in the ClientHello extension. (they are only permissible in the ClientHello extension); this
applies to arbitrary_explicit_prime_curves(0xFF01) and
arbitrary_explicit_char2_curves(0xFF02).
struct { struct {
ECParameters curve_params; ECParameters curve_params;
ECPoint public; ECPoint public;
} ServerECDHParams; } ServerECDHParams;
curve_params: Specifies the elliptic curve domain parameters curve_params: Specifies the elliptic curve domain parameters
associated with the ECDH public key. associated with the ECDH public key.
public: The ephemeral ECDH public key. public: The ephemeral ECDH public key.
skipping to change at page 22, line 36 skipping to change at page 22, line 36
ecdsa_fixed_ecdh(??), (255) ecdsa_fixed_ecdh(??), (255)
} ClientCertificateType; } ClientCertificateType;
ecdsa_sign, etc Indicates that the server would like to use the ecdsa_sign, etc Indicates that the server would like to use the
corresponding client authentication method specified in Section 3. corresponding client authentication method specified in Section 3.
[[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and [[ EDITOR: The values used for ecdsa_sign, rsa_fixed_ecdh, and
ecdsa_fixed_ecdh have been left as ??. These values will be ecdsa_fixed_ecdh have been left as ??. These values will be
assigned when this draft progresses to RFC. Earlier versions of assigned when this draft progresses to RFC. Earlier versions of
this draft used the values 5, 6, and 7 - however these values have this draft used the values 5, 6, and 7 - however these values have
been removed since they are used differently by SSL 3.0 [14] and been removed since they are used differently by SSL 3.0 [15] and
their use by TLS is being deprecated. ]] their use by TLS is being deprecated. ]]
Actions of the sender: Actions of the sender:
The server decides which client authentication methods it would like The server decides which client authentication methods it would like
to use, and conveys this information to the client using the format to use, and conveys this information to the client using the format
defined above. defined above.
Actions of the receiver: Actions of the receiver:
skipping to change at page 28, line 49 skipping to change at page 28, line 49
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? }
Table 5: TLS ECC cipher suites Table 5: TLS ECC cipher suites
[[ EDITOR: The actual cipher suite numbers will be assigned when this [[ EDITOR: The actual cipher suite numbers will be assigned when this
draft progresses to RFC. ]] draft progresses to RFC. ]]
The key exchange method, cipher, and hash algorithm for each of these The key exchange method, cipher, and hash algorithm for each of these
cipher suites are easily determined by examining the name. Ciphers cipher suites are easily determined by examining the name. Ciphers
other than AES ciphers, and hash algorithms are defined in [2]. AES other than AES ciphers, and hash algorithms are defined in [2]. AES
ciphers are defined in [15]. ciphers are defined in [16].
Server implementations SHOULD support all of the following cipher Server implementations SHOULD support all of the following cipher
suites, and client implementations SHOULD support at least one of suites, and client implementations SHOULD support at least one of
them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, them: TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, and
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA. TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
7. Security Considerations 7. Security Considerations
This document is based on [2], [5], [6] and [15]. The appropriate This document is based on [2], [5], [6] and [16]. The appropriate
security considerations of those documents apply. security considerations of those documents apply.
One important issue that implementors and users must consider is One important issue that implementors and users must consider is
elliptic curve selection. Guidance on selecting an appropriate elliptic curve selection. Guidance on selecting an appropriate
elliptic curve size is given in Table 1. elliptic curve size is given in Table 1.
Beyond elliptic curve size, the main issue is elliptic curve Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible - thus elliptic curves with as little algebraic structure as possible - thus
random curves are more conservative than special curves such as random curves are more conservative than special curves such as
skipping to change at page 31, line 5 skipping to change at page 31, line 5
of server key compromise, while ECDH_ECDSA and ECDH_RSA do not. of server key compromise, while ECDH_ECDSA and ECDH_RSA do not.
Similarly if the client is providing a static, certified key, Similarly if the client is providing a static, certified key,
ECDSA_sign client authentication provides forward secrecy protection ECDSA_sign client authentication provides forward secrecy protection
in the event of client key compromise, while ECDSA_fixed_ECDH and in the event of client key compromise, while ECDSA_fixed_ECDH and
RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy RSA_fixed_ECDH do not. Thus to obtain complete forward secrecy
protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange, protection, ECDHE_ECDSA or ECDHE_RSA must be used for key exchange,
with ECDSA_sign used for client authentication if necessary. Here with ECDSA_sign used for client authentication if necessary. Here
again the security benefits of forward secrecy may need to be again the security benefits of forward secrecy may need to be
balanced against the improved efficiency offered by other options. balanced against the improved efficiency offered by other options.
8. Acknowledgments 8. IANA Considerations
This document describes three new name spaces for use with the TLS
protocol:
o NamedCurve (Section 5.1)
o ECPointFormat (Section 5.1)
o ECCurveType (Section 5.4)
For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use. Any
additional assignments require IETF Consensus action [12].
9. Acknowledgments
The authors wish to thank Bill Anderson and Tim Dierks. The authors wish to thank Bill Anderson and Tim Dierks.
9. References 10. References
9.1 Normative References 10.1 Normative References
[1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement [1] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", [2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999. RFC 2246, January 1999.
[3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and [3] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
T. Wright, "Transport Layer Security (TLS) Extensions", T. Wright, "Transport Layer Security (TLS) Extensions",
draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005. draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005.
skipping to change at page 32, line 44 skipping to change at page 33, line 44
1.5", PKCS 1, November 1993. 1.5", PKCS 1, November 1993.
[10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, [10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2,
2000, <http://www.secg.org/>. 2000, <http://www.secg.org/>.
[11] Polk, T., Housley, R., and L. Bassham, "Algorithms and [11] Polk, T., Housley, R., and L. Bassham, "Algorithms and
Identifiers for the Internet X.509 Public Key Infrastructure Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile", Certificate and Certificate Revocation List (CRL) Profile",
RFC 3279, April 2002. RFC 3279, April 2002.
9.2 Informative References [12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998.
[12] Harper, G., Menezes, A., and S. Vanstone, "Public-Key 10.2 Informative References
[13] Harper, G., Menezes, A., and S. Vanstone, "Public-Key
Cryptosystems with Very Small Key Lengths", Advances in Cryptosystems with Very Small Key Lengths", Advances in
Cryptology -- EUROCRYPT '92, LNCS 658, 1993. Cryptology -- EUROCRYPT '92, LNCS 658, 1993.
[13] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [14] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key
Sizes", Journal of Cryptology 14 (2001) 255-293, Sizes", Journal of Cryptology 14 (2001) 255-293,
<http://www.cryptosavvy.com/>. <http://www.cryptosavvy.com/>.
[14] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol [15] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol
Version 3.0", November 1996, Version 3.0", November 1996,
<http://wp.netscape.com/eng/ssl3/draft302.txt>. <http://wp.netscape.com/eng/ssl3/draft302.txt>.
[15] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [16] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for
Transport Layer Security (TLS)", RFC 3268, June 2002. Transport Layer Security (TLS)", RFC 3268, June 2002.
Authors' Addresses Authors' Addresses
Vipul Gupta Vipul Gupta
Sun Microsystems Laboratories Sun Microsystems Laboratories
16 Network Circle 16 Network Circle
MS UMPK16-160 MS UMPK16-160
Menlo Park, CA 94025 Menlo Park, CA 94025
US US
 End of changes. 30 change blocks. 
53 lines changed or deleted 87 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/