< draft-ietf-tls-ecc-11.txt   draft-ietf-tls-ecc-12.txt >
TLS Working Group V. Gupta TLS Working Group S. Blake-Wilson
Internet-Draft Sun Labs Internet-Draft BCI
Expires: March 20, 2006 S. Blake-Wilson Expires: April 20, 2006 N. Bolyard
BCI Sun
V. Gupta
Sun Labs
C. Hawk
Corriente
B. Moeller B. Moeller
University of Calgary University of Calgary
C. Hawk October 17, 2005
Corriente Networks
N. Bolyard
September 16, 2005
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-11.txt> <draft-ietf-tls-ecc-12.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 41
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 March 20, 2006. This Internet-Draft will expire on April 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
Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of Diffie-Hellman (ECDH) key agreement in a TLS handshake and the use of
Elliptic Curve Digital Signature Algorithm (ECDSA) as a new Elliptic Curve Digital Signature Algorithm (ECDSA) as a new
authentication mechanism. authentication mechanism.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
Please send comments on this document to the TLS mailing list.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . 5 2. Key Exchange Algorithms . . . . . . . . . . . . . . . . . . . 5
2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1 ECDH_ECDSA . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7 2.2 ECDHE_ECDSA . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3 ECDH_RSA . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7 2.4 ECDHE_RSA . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 ECDH_anon . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Client Authentication . . . . . . . . . . . . . . . . . . . 9 3. Client Authentication . . . . . . . . . . . . . . . . . . . . 9
3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1 ECDSA_sign . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10 3.2 ECDSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . 10
3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10 3.3 RSA_fixed_ECDH . . . . . . . . . . . . . . . . . . . . . . 10
4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . 11 4. TLS Extensions for ECC . . . . . . . . . . . . . . . . . . . . 11
5. Data Structures and Computations . . . . . . . . . . . . . . 12 5. Data Structures and Computations . . . . . . . . . . . . . . . 12
5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12 5.1 Client Hello Extensions . . . . . . . . . . . . . . . . . 12
5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 15 5.1.1 Supported Elliptic Curves Extension . . . . . . . . . 13
5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 16 5.1.2 Supported Point Formats Extension . . . . . . . . . . 15
5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18 5.2 Server Hello Extension . . . . . . . . . . . . . . . . . . 16
5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22 5.3 Server Certificate . . . . . . . . . . . . . . . . . . . . 17
5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23 5.4 Server Key Exchange . . . . . . . . . . . . . . . . . . . 18
5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 24 5.5 Certificate Request . . . . . . . . . . . . . . . . . . . 22
5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 25 5.6 Client Certificate . . . . . . . . . . . . . . . . . . . . 23
5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 26 5.7 Client Key Exchange . . . . . . . . . . . . . . . . . . . 25
5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . 26 5.8 Certificate Verify . . . . . . . . . . . . . . . . . . . . 26
6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . 28 5.9 Elliptic Curve Certificates . . . . . . . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . 30 5.10 ECDH, ECDSA and RSA Computations . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 6. Cipher Suites . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33
10.1 Normative References . . . . . . . . . . . . . . . . . . 33 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34
10.2 Informative References . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 10.1 Normative References . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . 36 10.2 Informative References . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . 38
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, in particular for mobile (i.e., wireless)
to currently prevalent cryptosystems such as RSA, ECC offers environments. Compared to currently prevalent cryptosystems such as
equivalent security with smaller key sizes. This is illustrated in RSA, ECC offers equivalent security with smaller key sizes. This is
the following table, based on [14], which gives approximate illustrated in the following table, based on [16], which gives
comparable key sizes for symmetric- and asymmetric-key cryptosystems approximate comparable key sizes for symmetric- and asymmetric-key
based on the best-known algorithms for attacking them. cryptosystems 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
Table 1: Comparable key sizes (in bits) Table 1: Comparable key sizes (in bits)
Smaller key sizes result in power, bandwidth and computational Smaller key sizes result in savings for power, memory, bandwidth, and
savings that make ECC especially attractive for constrained computational cost that make ECC especially attractive for
environments. constrained environments.
This document describes additions to TLS to support ECC. In This document describes additions to TLS to support ECC, applicable
both to TLS Version 1.0 [2] and to TLS Version 1.1 [3]. In
particular, it defines particular, it defines
o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement o the use of the Elliptic Curve Diffie-Hellman (ECDH) key agreement
scheme with long-term or ephemeral keys to establish the TLS scheme with long-term or ephemeral keys to establish the TLS
premaster secret, and premaster secret, and
o the use of fixed-ECDH certificates and ECDSA for authentication of o the use of fixed-ECDH certificates and ECDSA for authentication of
TLS peers. TLS peers.
The remainder of this document is organized as follows. Section 2 The remainder of this document is organized as follows. Section 2
skipping to change at page 3, line 51 skipping to change at page 4, line 4
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 discusses security implementations of this specification. Section 7 discusses security
considerations. Section 8 describes IANA considerations for the name considerations. Section 8 describes IANA considerations for the name
spaces created by this document. Section 9 gives acknowledgments. spaces created by this document. Section 9 gives acknowledgments.
This is followed by the lists of normative and informative references This is followed by the lists of normative and informative references
cited in this document, the authors' contact information, and cited in this document, the authors' contact information, and
statements on intellectual property rights and copyrights. 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][3], TLS extensions [4], and ECC [5][6][7][9].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].
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
of the TLS master secret from the premaster secret and the subsequent of the TLS master secret from the premaster secret and the subsequent
generation of bulk encryption/MAC keys and initialization vectors is generation of bulk encryption/MAC keys and initialization vectors is
independent of the key exchange algorithm and not impacted by the independent of the key exchange algorithm and not impacted by the
introduction of ECC. introduction of ECC.
The table below summarizes the new key exchange algorithms which The table below summarizes the new key exchange algorithms which
mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2]), mimic DH_DSS, DHE_DSS, DH_RSA, DHE_RSA, and DH_anon (see [2] and
respectively. [3]), respectively.
Key Key
Exchange Exchange
Algorithm Description Algorithm Description
--------- ----------- --------- -----------
ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates. ECDH_ECDSA Fixed ECDH with ECDSA-signed certificates.
ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures. ECDHE_ECDSA Ephemeral ECDH with ECDSA signatures.
skipping to change at page 5, line 46 skipping to change at page 5, line 46
The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward The ECDHE_ECDSA and ECDHE_RSA key exchange mechanisms provide forward
secrecy. With ECDHE_RSA, a server can reuse its existing RSA secrecy. With ECDHE_RSA, a server can reuse its existing RSA
certificate and easily comply with a constrained client's elliptic certificate and easily comply with a constrained client's elliptic
curve preferences (see Section 4). However, the computational cost curve preferences (see Section 4). However, the computational cost
incurred by a server is higher for ECDHE_RSA than for the traditional incurred by a server is higher for ECDHE_RSA than for the traditional
RSA key exchange which does not provide forward secrecy. RSA key exchange which does not provide forward secrecy.
The ECDH_RSA mechanism requires a server to acquire an ECC The ECDH_RSA mechanism requires a server to acquire an ECC
certificate but the certificate issuer can still use an existing RSA certificate but the certificate issuer can still use an existing RSA
key for signing. This eliminates the need to update the trusted key key for signing. This eliminates the need to update the keys of
store in TLS clients. The ECDH_ECDSA mechanism requires ECC keys for trusted certificiation authorities accepted by TLS clients. The
the server as well as the certification authority and is best suited ECDH_ECDSA mechanism requires ECC keys for the server as well as the
for constrained devices unable to support RSA. certification authority and is best suited for constrained devices
unable to support RSA.
The anonymous key exchange algorithm does not provide authentication The anonymous key exchange algorithm does not provide authentication
of the server or the client. Like other anonymous TLS key exchanges, of the server or the client. Like other anonymous TLS key exchanges,
it is subject to man-in-the-middle attacks. Implementations of this it is subject to man-in-the-middle attacks. Implementations of this
algorithm SHOULD provide authentication by other means. algorithm SHOULD provide authentication by other means.
Note that there is no structural difference between ECDH and ECDSA Note that there is no structural difference between ECDH and ECDSA
keys. A certificate issuer may use X509.v3 keyUsage and keys. A certificate issuer may use X.509 v3 keyUsage and
extendedKeyUsage extensions to restrict the use of an ECC public key extendedKeyUsage extensions to restrict the use of an ECC public key
to certain computations. This document refers to an ECC key as ECDH- to certain computations [13]. This document refers to an ECC key as
capable if its use in ECDH is permitted. ECDSA-capable is defined ECDH-capable if its use in ECDH is permitted. ECDSA-capable is
similarly. defined similarly.
Client Server Client Server
------ ------ ------ ------
ClientHello --------> ClientHello -------->
ServerHello ServerHello
Certificate* Certificate*
ServerKeyExchange* ServerKeyExchange*
CertificateRequest*+ CertificateRequest*+
<-------- ServerHelloDone <-------- ServerHelloDone
skipping to change at page 7, line 24 skipping to change at page 7, line 25
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 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.
The server sends its ephemeral ECDH public key and a specification of The server sends its ephemeral ECDH public key and a specification of
the corresponding curve in the ServerKeyExchange message. These the corresponding curve in the ServerKeyExchange message. These
parameters MUST be signed with ECDSA using the private key parameters MUST be signed with ECDSA using the private key
corresponding to the public key in the server's Certificate. corresponding to the public key in the server's Certificate.
skipping to change at page 8, line 29 skipping to change at page 8, line 30
server's ephemeral ECDH key and send its public key in the server's ephemeral ECDH key and send its public key in the
ClientKeyExchange message. ClientKeyExchange message.
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.
Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA Note that while the ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, and ECDHE_RSA
key exchange algorithms require the server's certificate to be signed key exchange algorithms require the server's certificate to be signed
with a particular signature scheme, this specification (following the with a particular signature scheme, this specification (following the
similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2] and [3])
impose restrictions on signature schemes used elsewhere in the does not impose restrictions on signature schemes used elsewhere in
certificate chain. (Often such restrictions will be useful, and it the certificate chain. (Often such restrictions will be useful, and
is expected that this will be taken into account in certification it is expected that this will be taken into account in certification
authorities' signing practices. However, such restrictions are not authorities' signing practices. However, such restrictions are not
strictly required in general: Even if it is beyond the capabilities strictly required in general: Even if it is beyond the capabilities
of a client to completely validate a given chain, the client may be of a client to completely validate a given chain, the client may be
able to validate the server's certificate by relying on a trust able to validate the server's certificate by relying on a trusted
anchor that appears as one of the intermediate certificates in the certification authority whose certificate appears as one of the
chain.) intermediate certificates in the chain.)
3. Client Authentication 3. Client Authentication
This document defines three new client authentication mechanisms This document defines three new client authentication mechanisms
named after the type of client certificate involved: ECDSA_sign, named after the type of client certificate involved: ECDSA_sign,
ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is ECDSA_fixed_ECDH and RSA_fixed_ECDH. The ECDSA_sign mechanism is
usable with any of the non-anonymous ECC key exchange algorithms usable with any of the non-anonymous ECC key exchange algorithms
described in Section 2 as well as other non-anonymous (non-ECC) key described in Section 2 as well as other non-anonymous (non-ECC) key
exchange algorithms defined in TLS [2]. The ECDSA_fixed_ECDH and exchange algorithms defined in TLS [2][3]. The ECDSA_fixed_ECDH and
RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA. RSA_fixed_ECDH mechanisms are usable with ECDH_ECDSA and ECDH_RSA.
Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the Their use with ECDHE_ECDSA and ECDHE_RSA is prohibited because the
use of a long-term ECDH client key would jeopardize the forward use of a long-term ECDH client key would jeopardize the forward
secrecy property of these algorithms. secrecy property of these algorithms.
The server can request ECC-based client authentication by including The server can request ECC-based client authentication by including
one or more of these certificate types in its CertificateRequest one or more of these certificate types in its CertificateRequest
message. The server must not include any certificate types that are message. The server must not include any certificate types that are
prohibited for the negotiated key exchange algorithm. The client prohibited for the negotiated key exchange algorithm. The client
must check if it possesses a certificate appropriate for any of the must check if it possesses a certificate appropriate for any of the
skipping to change at page 11, line 14 skipping to change at page 11, line 14
4. TLS Extensions for ECC 4. TLS Extensions for ECC
Two new TLS extensions are defined in this specification: (i) the Two new TLS extensions are defined in this specification: (i) the
Supported Elliptic Curves Extension, and (ii) the Supported Point Supported Elliptic Curves Extension, and (ii) the Supported Point
Formats Extension. These allow negotiating the use of specific Formats Extension. These allow negotiating the use of specific
curves and point formats (e.g. compressed vs. uncompressed), curves and point formats (e.g. compressed vs. uncompressed),
respectively, during a handshake starting a new session. These respectively, during a handshake starting a new session. These
extensions are especially relevant for constrained clients that may extensions are especially relevant for constrained clients that may
only support a limited number of curves or point formats. They only support a limited number of curves or point formats. They
follow the general approach outlined in [3]; message details are follow the general approach outlined in [4]; message details are
specified in Section 5. The client enumerates the curves it supports specified in Section 5. The client enumerates the curves it supports
and the point formats it can parse by including the appropriate and the point formats it can parse by including the appropriate
extensions in its ClientHello message. The server similarly extensions in its ClientHello message. The server similarly
enumerates the point formats it can parse by including an extension enumerates the point formats it can parse by including an extension
in its ServerHello message. in its ServerHello message.
A TLS client that proposes ECC cipher suites in its ClientHello A TLS client that proposes ECC cipher suites in its ClientHello
message SHOULD include these extensions. Servers implementing ECC message SHOULD include these extensions. Servers implementing ECC
cipher suites MUST support these extensions, and when a client uses cipher suites MUST support these extensions, and when a client uses
these extensions, servers MUST NOT negotiate the use of an ECC cipher these extensions, servers MUST NOT negotiate the use of an ECC cipher
suite unless they can complete the handshake while respecting the suite unless they can complete the handshake while respecting the
choice of curves and compression techniques specified by the client. choice of curves and compression techniques specified by the client.
This eliminates the possibility that a negotiated ECC handshake will This eliminates the possibility that a negotiated ECC handshake will
be subsequently aborted due to a client's inability to deal with the be subsequently aborted due to a client's inability to deal with the
server's EC key. server's EC key.
These extensions MUST NOT be included if the client does not propose The client MUST NOT include these extensions in the ClientHello
any ECC cipher suites. A client that proposes ECC cipher suites may message if it does not propose any ECC cipher suites. A client that
choose not to include these extension. In this case, the server is proposes ECC cipher suites may choose not to include these extension.
free to choose any one of the elliptic curves or point formats listed In this case, the server is free to choose any one of the elliptic
in Section 5. That section also describes the structure and curves or point formats listed in Section 5. That section also
processing of these extensions in greater detail. describes the structure and processing of these extensions in greater
detail.
In the case of session resumption, the server simply ignores the In the case of session resumption, the server simply ignores the
Supported Elliptic Curves Extension and the Supported Point Formats Supported Elliptic Curves Extension and the Supported Point Formats
Extension as appearing in the current ClientHello message. These Extension as appearing in the current ClientHello message. These
extensions only play a role during handshakes negotiating a new extensions only play a role during handshakes negotiating a new
session. session.
5. Data Structures and Computations 5. Data Structures and Computations
This section specifies the data structures and computations used by This section specifies the data structures and computations used by
ECC-based key mechanisms specified in Section 2, Section 3 and ECC-based key mechanisms specified in Section 2, Section 3 and
Section 4. The presentation language used here is the same as that Section 4. The presentation language used here is the same as that
used in TLS [2]. Since this specification extends TLS, these used in TLS [2][3]. Since this specification extends TLS, these
descriptions should be merged with those in the TLS specification and descriptions should be merged with those in the TLS specification and
any others that extend TLS. This means that enum types may not any others that extend TLS. This means that enum types may not
specify all possible values and structures with multiple formats specify all possible values and structures with multiple formats
chosen with a select() clause may not indicate all possible cases. chosen with a select() clause may not indicate all possible cases.
5.1 Client Hello Extensions 5.1 Client Hello Extensions
This section specifies two TLS extensions that can be included with This section specifies two TLS extensions that can be included with
the ClientHello message as described in [3], the Supported Elliptic the ClientHello message as described in [4], the Supported Elliptic
Curves Extension and the Supported Point Formats Extension. Curves Extension and the Supported Point Formats Extension.
When these extensions are sent: When these extensions are sent:
The extensions SHOULD be sent along with any ClientHello message that The extensions SHOULD be sent along with any ClientHello message that
proposes ECC cipher suites. proposes ECC cipher suites.
Meaning of these extensions: Meaning of these extensions:
These extensions allow a client to enumerate the elliptic curves it These extensions allow a client to enumerate the elliptic curves it
supports and/or the point formats it can parse. supports and/or the point formats it can parse.
Structure of these extensions: Structure of these extensions:
The general structure of TLS extensions is described in [3] and this The general structure of TLS extensions is described in [4] and this
specification adds two new types to ExtensionType. specification adds two new types to ExtensionType.
enum { elliptic_curves(??), ec_point_formats(??) } ExtensionType; enum { elliptic_curves(10), ec_point_formats(11) } ExtensionType;
[[ EDITOR: The values used for elliptic_curves and ec_point_formats [[ EDITOR: The values "10" and "11" used for the new extensions are
have been left as ??. These values will be assigned when this draft tentative! (They were picked to avoid conflicts with other emerging
progresses to RFC. (The examples below will have to be changed specifications; see http://people.nokia.net/~pasi/tls-numbers.txt .)
accordingly.) ]] Final assignments in accordance with [4] will be done by IANA. The
values appearing in this Internet-Draft represent the authors'
recommendations to IANA for assignments. ]]
elliptic_curves (Supported Elliptic Curves Extension): Indicates the elliptic_curves (Supported Elliptic Curves Extension): Indicates the
set of elliptic curves supported by the client. For this set of elliptic curves supported by the client. For this
extension, the opaque extension_data field contains extension, the opaque extension_data field contains
EllipticCurveList. EllipticCurveList. See Section 5.1.1 for details.
ec_point_formats (Supported Point Formats Extension): Indicates the ec_point_formats (Supported Point Formats Extension): Indicates the
set of point formats that the client can parse. For this set of point formats that the client can parse. For this
extension, the opaque extension_data field contains extension, the opaque extension_data field contains
ECPointFormatList. ECPointFormatList. See Section 5.1.2 for details.
Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello message
appends these extensions (along with any others), enumerating the
curves it supports and the point formats it can parse. Clients
SHOULD send both the Supported Elliptic Curves Extension and the
Supported Point Formats Extension. If the Supported Point Formats
Extension is indeed sent, it MUST contain the value 0 (uncompressed)
as one of the items in the list of point formats.
Actions of the receiver:
A server that receives a ClientHello containing one or both of these
extensions MUST use the client's enumerated capabilities to guide its
selection of an appropriate cipher suite. One of the proposed ECC
cipher suites must be negotiated only if the server can successfully
complete the handshake while using the curves and point formats
supported by the client (cf. Section 5.3 and Section 5.4).
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message. The server
must consider the extensions in both cases.
If a server does not understand the Supported Elliptic Curves
Extension or does not understand the Supported Point Formates
Extension or is unable to complete the ECC handshake while
restricting itself to the enumerated curves and point formats, it
MUST NOT negotiate the use of an ECC cipher suite. Depending on what
other cipher suites are proposed by the client and supported by the
server, this may result in a fatal handshake failure alert due to the
lack of common cipher suites.
5.1.1 Supported Elliptic Curves Extension
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), secp521r1 (25),
reserved (0xFE00..0xFEFF), reserved (0xFE00..0xFEFF),
arbitrary_explicit_prime_curves(0xFF01), arbitrary_explicit_prime_curves(0xFF01),
arbitrary_explicit_char2_curves(0xFF02), arbitrary_explicit_char2_curves(0xFF02),
(0xFFFF) (0xFFFF)
} NamedCurve; } NamedCurve;
sect163k1, etc: Indicates support of the corresponding named curve sect163k1, etc: Indicates support of the corresponding named curve
or class of explicitly defined curves. The named curves defined or class of explicitly defined curves. The named curves defined
here are those specified in SEC 2 [10]. Note that many of these here are those specified in SEC 2 [11]. Note that many of these
curves are also recommended in ANSI X9.62 [6] and FIPS 186-2 [8]. curves are also recommended in ANSI X9.62 [7] and FIPS 186-2 [9].
Values 0xFE00 through 0xFEFF are reserved for private use. Values Values 0xFE00 through 0xFEFF are reserved for private use. Values
0xFF01 and 0xFF02 indicate that the client supports arbitrary 0xFF01 and 0xFF02 indicate that the client supports arbitrary
prime and characteristic-2 curves, respectively (the curve prime and characteristic-2 curves, respectively (the curve
parameters must be encoded explicitly in ECParameters). parameters must be encoded explicitly in ECParameters).
The NamedCurve name space is maintained by IANA. See Section 8 for The NamedCurve name space is maintained by IANA. See Section 8 for
information on how new value assignments are added. 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 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015) value 19 = 0x0013) and secp224r1 (aka NIST P-224; value 21 = 0x0015)
and prefers to use secp192r1 would include a TLS extension consisting and prefers to use secp192r1 would include a TLS extension consisting
of the following octets: of the following octets; note that the first two octets indicate the
extension type (Supported Elliptic Curves Extension):
00 ?? 00 06 00 04 00 13 00 15 00 0A 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 0xFF02) would include an extension consisting of the following (value 0xFF02) would include an extension consisting of the following
octets: octets:
00 ?? 00 04 00 02 FF 02 00 0A 00 04 00 02 FF 02
[[ EDITOR: As noted above, the extension type value appearing in this
example is tentative. ]]
5.1.2 Supported Point Formats Extension
enum { uncompressed (0), ansiX962_compressed_prime (1), enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_compressed_char2 (2), reserved (248..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. (These formats are specified in only to characteristic-2 curves. (These formats are specified in
[6].) Values 248 through 255 are reserved for private use. [7].) Values 248 through 255 are reserved for private use.
The ECPointFormat name space is maintained by IANA. See Section 8 The ECPointFormat name space is maintained by IANA. See Section 8
for information on how new value assignments are added. 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; note that
the first two octets indicate the extension type (Supported Point
Formats Extension):
00 ?? 00 02 01 00 00 0B 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
format (ansiX962_compressed_prime, value 1) over the uncompressed format (ansiX962_compressed_prime, value 1) over the uncompressed
format (value 0), but in the case of characteristic-2 fields prefers format (value 0), but in the case of characteristic-2 fields prefers
the uncompressed format (value 0) over the compressed format the uncompressed format (value 0) over the compressed format
(ansiX962_compressed_char2, value 2), may indicate these preferences (ansiX962_compressed_char2, value 2), may indicate these preferences
by including an extension consisting of the following octets: by including an extension consisting of the following octets:
00 ?? 00 04 03 01 00 02 00 0B 00 04 03 01 00 02
Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello message
appends these extensions (along with any others), enumerating the
curves it supports and the point formats it can parse. Clients
SHOULD send both the Supported Elliptic Curves Extension and the
Supported Point Formats Extension. If the Supported Point Formats
Extension is indeed sent, it MUST contain the value 0 (uncompressed)
as one of the items in the list of point formats.
Actions of the receiver:
A server that receives a ClientHello containing one or both of these
extensions MUST use the client's enumerated capabilities to guide its
selection of an appropriate cipher suite. One of the proposed ECC
cipher suites must be negotiated only if the server can successfully
complete the handshake while using the curves and point formats
supported by the client (cf. Section 5.3 and Section 5.4).
NOTE: A server participating in an ECDHE-ECDSA key exchange may use
different curves for (i) the ECDSA key in its certificate, and (ii)
the ephemeral ECDH key in the ServerKeyExchange message. The server
must consider the "elliptic_curves" extension in selecting both of
these curves.
If a server does not understand the "elliptic_curves" extension or is [[ EDITOR: As noted above, the extension type value appearing in this
unable to complete the ECC handshake while restricting itself to the example is tentative. ]]
enumerated curves, it MUST NOT negotiate the use of an ECC cipher
suite. Depending on what other cipher suites are proposed by the
client and supported by the server, this may result in a fatal
handshake failure alert due to the lack of common cipher suites.
5.2 Server Hello Extension 5.2 Server Hello Extension
This section specifies a TLS extension that can be included with the This section specifies a TLS extension that can be included with the
ServerHello message as described in [3], the Supported Point Formats ServerHello message as described in [4], the Supported Point Formats
Extension. Extension.
When this extension is sent: When this extension is sent:
The Supported Point Formats Extension is included in a ServerHello The Supported Point Formats Extension is included in a ServerHello
message in response to a ClientHello message containing the Supported message in response to a ClientHello message containing the Supported
Point Formats Extension when negotiating an ECC cipher suite. Point Formats Extension when negotiating an ECC cipher suite.
Meaning of this extensions: Meaning of this extensions:
This extension allows a server to enumerate the point formats it can This extension allows a server to enumerate the point formats it can
parse (for the curve that will appear in its ServerKeyExchange parse (for the curve that will appear in its ServerKeyExchange
message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key message when using the ECDHE_ECDSA, ECDHE_RSA, or ECDH_anon key
exchange algorithm, or for the curve that is used in the server's exchange algorithm, or for the curve that is used in the server's
public key that will appear in its Certificate message when using the public key that will appear in its Certificate message when using the
ECDH_ECDSA or ECDH_RSA key exchange algorithm). ECDH_ECDSA or ECDH_RSA key exchange algorithm).
Structure of this extension: Structure of this extension:
The server's Supported Point Formats Extension has the same structure The server's Supported Point Formats Extension has the same structure
as the client's Supported Point Formats Extension. Items in as the client's Supported Point Formats Extension (see
elliptic_curve_list here are ordered according to the server's Section 5.1.2). Items in elliptic_curve_list here are ordered
preference (favorite choice first). Note that the server may include according to the server's preference (favorite choice first). Note
items that were not found in the client's list (e.g., the server may that the server may include items that were not found in the client's
prefer to receive points in compressed format even when a client list (e.g., the server may prefer to receive points in compressed
cannot parse this format: the same client may nevertheless be capable format even when a client cannot parse this format: the same client
to output points in compressed format). may nevertheless be capable to output points in compressed format).
Actions of the sender: Actions of the sender:
A server that selects an ECC cipher suite in response to a A server that selects an ECC cipher suite in response to a
ClientHello message including a Supported Point Formats Extension ClientHello message including a Supported Point Formats Extension
appends this extension (along with others) to its ServerHello appends this extension (along with others) to its ServerHello
message, enumerating the point formats it can parse. The Supported message, enumerating the point formats it can parse. The Supported
Point Formats Extension, when used, MUST contain the value 0 Point Formats Extension, when used, MUST contain the value 0
(uncompressed) as one of the items in the list of point formats. (uncompressed) as one of the items in the list of point formats.
skipping to change at page 16, line 50 skipping to change at page 17, line 21
When this message is sent: When this message is sent:
This message is sent in all non-anonymous ECC-based key exchange This message is sent in all non-anonymous ECC-based key exchange
algorithms. algorithms.
Meaning of this message: Meaning of this message:
This message is used to authentically convey the server's static This message is used to authentically convey the server's static
public key to the client. The following table shows the server public key to the client. The following table shows the server
certificate type appropriate for each key exchange algorithm. ECC certificate type appropriate for each key exchange algorithm. ECC
public keys must be encoded in certificates as described in public keys MUST be encoded in certificates as described in
Section 5.9. Section 5.9.
NOTE: The server's Certificate message is capable of carrying a chain NOTE: The server's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 3 apply only to of certificates. The restrictions mentioned in Table 3 apply only to
the server's certificate (first in the chain). the server's certificate (first in the chain).
Key Exchange Algorithm Server Certificate Type Key Exchange Algorithm Server Certificate Type
---------------------- ----------------------- ---------------------- -----------------------
ECDH_ECDSA Certificate must contain an ECDH_ECDSA Certificate MUST contain an
ECDH-capable public key. It ECDH-capable public key. It
must be signed with ECDSA. MUST be signed with ECDSA.
ECDHE_ECDSA Certificate must contain an ECDHE_ECDSA Certificate MUST contain an
ECDSA-capable public key. It ECDSA-capable public key. It
must be signed with ECDSA. MUST be signed with ECDSA.
ECDH_RSA Certificate must contain an ECDH_RSA Certificate MUST contain an
ECDH-capable public key. It ECDH-capable public key. It
must be signed with RSA. MUST be signed with RSA.
ECDHE_RSA Certificate must contain an ECDHE_RSA Certificate MUST contain an
RSA public key authorized for RSA public key authorized for
use in digital signatures. It use in digital signatures. It
must be signed with RSA. MUST be signed with RSA.
Table 3: Server certificate types Table 3: Server certificate types
Structure of this message: Structure of this message:
Identical to the TLS Certificate format. Identical to the TLS Certificate format.
Actions of the sender: Actions of the sender:
The server constructs an appropriate certificate chain and conveys it The server constructs an appropriate certificate chain and conveys it
to the client in the Certificate message. If the client has used a to the client in the Certificate message. If the client has used a
Supported Elliptic Curves Extension, the public key in the server's Supported Elliptic Curves Extension, the public key in the server's
certificate MUST respect the client's choice of elliptic curves; in certificate MUST respect the client's choice of elliptic curves; in
particular, the public key MUST employ a named curve (not the same particular, the public key MUST employ a named curve (not the same
curve as an explicit curve) unless the client has indicated support curve as an explicit curve) unless the client has indicated support
for explicit curves of the appropriate type. If the client has used for explicit curves of the appropriate type. If the client has used
a Supported Point Formats Extension, both the server's public key a Supported Point Formats Extension, both the server's public key
point and (in the case of an explicit curve) the curve's base point point and (in the case of an explicit curve) the curve's base point
MUST respect the client's choice of point formats. (A server that MUST respect the client's choice of point formats. (A server that
cannot satisfy these requirements must not choose an ECC cipher suite cannot satisfy these requirements MUST NOT choose an ECC cipher suite
in its ServerHello message.) in its ServerHello message.)
Actions of the receiver: Actions of the receiver:
The client validates the certificate chain, extracts the server's The client validates the certificate chain, extracts the server's
public key, and checks that the key type is appropriate for the public key, and checks that the key type is appropriate for the
negotiated key exchange algorithm. negotiated key exchange algorithm. (A possible reason for a fatal
handshake failure is if the client's capabilities for handling
elliptic curves and point formats are exceeded; cf. Section 5.1.)
5.4 Server Key Exchange 5.4 Server Key Exchange
When this message is sent: When this message is sent:
This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and This message is sent when using the ECDHE_ECDSA, ECDHE_RSA and
ECDH_anon key exchange algorithms. ECDH_anon key exchange algorithms.
Meaning of this message: Meaning of this message:
skipping to change at page 18, line 51 skipping to change at page 19, line 29
information on how new value assignments are added. 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 [7].
struct { struct {
opaque point <1..2^8-1>; opaque point <1..2^8-1>;
} ECPoint; } ECPoint;
point: This is the byte string representation of an elliptic curve point: This is the byte string representation of an elliptic curve
point following the conversion routine in Section 4.3.6 of ANSI point following the conversion routine in Section 4.3.6 of ANSI
X9.62 [6]. This byte string may represent an elliptic curve point X9.62 [7]. This byte string may represent an elliptic curve point
in uncompressed, or compressed format; it MUST conform to what the in uncompressed, or compressed format; it MUST conform to what the
client has requested through a Supported Point Formats Extension client has requested through a Supported Point Formats Extension
if this extension was used. if this extension was used.
enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType;
ec_basis_trinomial: Indicates representation of a characteristic-2 ec_basis_trinomial: Indicates representation of a characteristic-2
field using a trinomial basis. field using a trinomial basis.
ec_basis_pentanomial: Indicates representation of a characteristic-2 ec_basis_pentanomial: Indicates representation of a characteristic-2
skipping to change at page 21, line 33 skipping to change at page 22, line 16
select (SignatureAlgorithm) { select (SignatureAlgorithm) {
case ecdsa: case ecdsa:
digitally-signed struct { digitally-signed struct {
opaque sha_hash[sha_size]; opaque sha_hash[sha_size];
}; };
} Signature; } Signature;
NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange
algorithm and "anonymous" for ECDH_anon. These cases are defined in algorithm and "anonymous" for ECDH_anon. These cases are defined in
TLS [2]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA TLS [2][3]. SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA. ECDSA
signatures are generated and verified as described in Section 5.10. signatures are generated and verified as described in Section 5.10.
As per ANSI X9.62, an ECDSA signature consists of a pair of integers As per ANSI X9.62, an ECDSA signature consists of a pair of integers
r and s. These integers are both converted into byte strings of the r and s. These integers are both converted into byte strings of the
same length as the curve order n using the conversion routine same length as the curve order n using the conversion routine
specified in Section 4.3.1 of [6]. The two byte strings are specified in Section 4.3.1 of [7]. The two byte strings are
concatenated, and the result is placed in the signature field. concatenated, and the result is placed in the signature field.
Actions of the sender: Actions of the sender:
The server selects elliptic curve domain parameters and an ephemeral The server selects elliptic curve domain parameters and an ephemeral
ECDH public key corresponding to these parameters according to the ECDH public key corresponding to these parameters according to the
ECKAS-DH1 scheme from IEEE 1363 [5]. It conveys this information to ECKAS-DH1 scheme from IEEE 1363 [6]. It conveys this information to
the client in the ServerKeyExchange message using the format defined the client in the ServerKeyExchange message using the format defined
above. above.
Actions of the recipient: Actions of the recipient:
The client verifies the signature (when present) and retrieves the The client verifies the signature (when present) and retrieves the
server's elliptic curve domain parameters and ephemeral ECDH public server's elliptic curve domain parameters and ephemeral ECDH public
key from the ServerKeyExchange message. key from the ServerKeyExchange message. (A possible reason for a
fatal handshake failure is if the client's capabilities for handling
elliptic curves and point formats are exceeded; cf. Section 5.1.)
5.5 Certificate Request 5.5 Certificate Request
When this message is sent: When this message is sent:
This message is sent when requesting client authentication. This message is sent when requesting client authentication.
Meaning of this message: Meaning of this message:
The server uses this message to suggest acceptable client The server uses this message to suggest acceptable client
authentication methods. authentication methods.
Structure of this message: Structure of this message:
The TLS CertificateRequest message is extended as follows. The TLS CertificateRequest message is extended as follows.
enum { enum {
ecdsa_sign(??), rsa_fixed_ecdh(??), ecdsa_sign(64), rsa_fixed_ecdh(65),
ecdsa_fixed_ecdh(??), (255) ecdsa_fixed_ecdh(66), (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 above client certificate type numbers are
ecdsa_fixed_ecdh have been left as ??. These values will be tentative! (See http://www.iana.org/assignments/tls-parameters
assigned when this draft progresses to RFC. Earlier versions of for the registry.) Final assignments to the TLS
this draft used the values 5, 6, and 7 - however these values have ClientCertificateType Identifiers Registry in accordance with [3]
been removed since they are used differently by SSL 3.0 [15] and will be done by IANA. The values appearing in this Internet-Draft
their use by TLS is being deprecated. ]] represent the authors' recommendations to IANA for assignments. ]]
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:
The client determines whether it has a suitable certificate for use The client determines whether it has a suitable certificate for use
skipping to change at page 25, line 28 skipping to change at page 26, line 15
struct { struct {
select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) {
case ec_diffie_hellman: ClientECDiffieHellmanPublic; case ec_diffie_hellman: ClientECDiffieHellmanPublic;
} exchange_keys; } exchange_keys;
} ClientKeyExchange; } ClientKeyExchange;
Actions of the sender: Actions of the sender:
The client selects an ephemeral ECDH public key corresponding to the The client selects an ephemeral ECDH public key corresponding to the
parameters it received from the server according to the ECKAS-DH1 parameters it received from the server according to the ECKAS-DH1
scheme from IEEE 1363 [5]. It conveys this information to the client scheme from IEEE 1363 [6]. It conveys this information to the client
in the ClientKeyExchange message using the format defined above. in the ClientKeyExchange message using the format defined above.
Actions of the recipient: Actions of the recipient:
The server retrieves the client's ephemeral ECDH public key from the The server retrieves the client's ephemeral ECDH public key from the
ClientKeyExchange message and checks that it is on the same elliptic ClientKeyExchange message and checks that it is on the same elliptic
curve as the server's ECDH key. curve as the server's ECDH key.
5.8 Certificate Verify 5.8 Certificate Verify
skipping to change at page 26, line 24 skipping to change at page 27, line 8
opaque sha_hash[sha_size]; opaque sha_hash[sha_size];
}; };
} Signature; } Signature;
For the ecdsa case, the signature field in the CertificateVerify For the ecdsa case, the signature field in the CertificateVerify
message contains an ECDSA signature computed over handshake messages message contains an ECDSA signature computed over handshake messages
exchanged so far. ECDSA signatures are computed as described in exchanged so far. ECDSA signatures are computed as described in
Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a Section 5.10. As per ANSI X9.62, an ECDSA signature consists of a
pair of integers r and s. These integers are both converted into pair of integers r and s. These integers are both converted into
byte strings of the same length as the curve order n using the byte strings of the same length as the curve order n using the
conversion routine specified in Section 4.3.1 of [6]. The two byte conversion routine specified in Section 4.3.1 of [7]. The two byte
strings are concatenated, and the result is placed in the signature strings are concatenated, and the result is placed in the signature
field. field.
Actions of the sender: Actions of the sender:
The client computes its signature over all handshake messages sent or The client computes its signature over all handshake messages sent or
received starting at client hello up to but not including this received starting at client hello up to but not including this
message. It uses the private key corresponding to its certified message. It uses the private key corresponding to its certified
public key to compute the signature which is conveyed in the format public key to compute the signature which is conveyed in the format
defined above. defined above.
Actions of the receiver: Actions of the receiver:
The server extracts the client's signature from the CertificateVerify The server extracts the client's signature from the CertificateVerify
message, and verifies the signature using the public key it received message, and verifies the signature using the public key it received
in the client's Certificate message. in the client's Certificate message.
5.9 Elliptic Curve Certificates 5.9 Elliptic Curve Certificates
X509 certificates containing ECC public keys or signed using ECDSA X.509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [11] or another RFC that replaces or extends it. MUST comply with [12] or another RFC that replaces or extends it.
Clients SHOULD use the elliptic curve domain parameters recommended Clients SHOULD use the elliptic curve domain parameters recommended
in ANSI X9.62 [6], FIPS 186-2 [8], and SEC 2 [10]. in ANSI X9.62 [7], FIPS 186-2 [9], and SEC 2 [11].
5.10 ECDH, ECDSA and RSA Computations 5.10 ECDH, ECDSA and RSA Computations
All ECDH calculations (including parameter and key generation as well All ECDH calculations (including parameter and key generation as well
as the shared secret calculation) are performed according to [5] as the shared secret calculation) are performed according to [6]
using the ECKAS-DH1 scheme with the identity map as key derivation using the ECKAS-DH1 scheme with the identity map as key derivation
function, so that the premaster secret is the x-coordinate of the function (KDF), so that the premaster secret is the x-coordinate of
ECDH shared secret elliptic curve point represented as an octet the ECDH shared secret elliptic curve point represented as an octet
string. Note that this octet string (Z in IEEE 1363 terminology) as string. Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated. found in this octet string MUST NOT be truncated.
Note that a new extension may be introduced in the future to allow (Note that this use of the identity KDF is a technicality. The
the use of a different KDF during computation of the premaster complete picture is that ECDH is employed with a non-trivial KDF
secret. In this event, the new KDF would be used in place of the because TLS does not directly use the premaster secret for anything
process detailed above. This may be desirable, for example, to other than for computing the master secret. As of TLS 1.0 [2] and
support compatibility with the planned NIST key agreement standard. 1.1 [3] this means that the MD5- and SHA-1-based TLS PRF serves as a
KDF; it is conceivable that future TLS versions or new TLS extensions
All ECDSA computations MUST be performed according to ANSI X9.62 [6] introduced in the future may vary this computation.)
All ECDSA computations MUST be performed according to ANSI X9.62 [7]
or its successors. Data to be signed/verified is hashed and the or its successors. Data to be signed/verified is hashed and the
result run directly through the ECDSA algorithm with no additional result run directly through the ECDSA algorithm with no additional
hashing. The default hash function is SHA-1 [7] and sha_size (see hashing. The default hash function is SHA-1 [8] and sha_size (see
Section 5.4 and Section 5.8) is 20. However, an alternative hash Section 5.4 and Section 5.8) is 20. However, an alternative hash
function, such as one of the new SHA hash functions specified in FIPS function, such as one of the new SHA hash functions specified in FIPS
180-2 [7], may be used instead if the certificate containing the EC 180-2 [8], may be used instead if the certificate containing the EC
public key explicitly requires use of another hash function. (The public key explicitly requires use of another hash function. (The
mechanism for specifying the required hash function has not been mechanism for specifying the required hash function has not been
standardized but this provision anticipates such standardization and standardized but this provision anticipates such standardization and
obviates the need to update this document in response. Future PKIX obviates the need to update this document in response. Future PKIX
RFCs may choose, for example, to specify the hash function to be used RFCs may choose, for example, to specify the hash function to be used
with a public key in the parameters field of subjectPublicKeyInfo.) with a public key in the parameters field of subjectPublicKeyInfo.)
All RSA signatures must be generated and verified according to PKCS#1 All RSA signatures must be generated and verified according to PKCS#1
[9] block type 1. [10] block type 1.
6. Cipher Suites 6. Cipher Suites
The table below defines new ECC cipher suites that use the key The table below defines new ECC cipher suites that use the key
exchange algorithms specified in Section 2. exchange algorithms specified in Section 2.
CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_NULL_SHA = { 0xC0, 0x00 }
CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x01 }
CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_DES_CBC_SHA = { 0xC0, 0x02 }
CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x03 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x04 }
CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x05 }
CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_NULL_SHA = { 0xC0, 0x06 }
CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_RC4_128_SHA = { 0xC0, 0x07 }
CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x08 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x09 }
CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0A }
CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_NULL_SHA = { 0xC0, 0x0B }
CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_RC4_128_SHA = { 0xC0, 0x0C }
CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x0D }
CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x0E }
CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x0F }
CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_NULL_SHA = { 0xC0, 0x10 }
CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_RC4_128_SHA = { 0xC0, 0x11 }
CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x12 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA = { 0xC0, 0x13 }
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA = { 0xC0, 0x14 }
CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_NULL_WITH_SHA = { 0xC0, 0x15 }
CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_RC4_128_SHA = { 0xC0, 0x16 }
CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA = { 0xC0, 0x17 }
CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_128_CBC_SHA = { 0xC0, 0x18 }
CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x?? } CipherSuite TLS_ECDH_anon_WITH_AES_256_CBC_SHA = { 0xC0, 0x19 }
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 above cipher suite numbers are tentative! (See
draft progresses to RFC. ]] http://www.iana.org/assignments/tls-parameters for the registry.)
Final assignments to the TLS Cipher Suite Registry in accordance with
[3] will be done by IANA. The values appearing in this Internet-
Draft represent the authors' recommendations to IANA for assignments.
]]
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] and
ciphers are defined in [16]. [3]. AES ciphers are defined in [18].
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 [16]. The appropriate Security issues are discussed throughout this memo.
security considerations of those documents apply.
For TLS handshakes using ECC cipher suites, the security
considerations in appendices D.2 and D.3 of [2] and [3] apply
accordingly.
Security discussions specific to ECC can be found in [6] and [7].
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
Koblitz curves, and curves over F_p with p random are more Koblitz curves, and curves over F_p with p random are more
conservative than curves over F_p with p of a special form (and conservative than curves over F_p with p of a special form (and
curves over F_p with p random might be considered more conservative curves over F_p with p random might be considered more conservative
than curves over F_2^m as there is no choice between multiple fields than curves over F_2^m as there is no choice between multiple fields
of similar size for characteristic 2). Note, however, that algebraic of similar size for characteristic 2). Note, however, that algebraic
structure can also lead to implementation efficiencies and structure can also lead to implementation efficiencies and
implementors and users may, therefore, need to balance conservatism implementors and users may, therefore, need to balance conservatism
against a need for efficiency. Concrete attacks are known against against a need for efficiency. Concrete attacks are known against
only very few special classes of curves, such as supersingular only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards that curves, and these classes are excluded from the ECC standards that
this document references [5], [6]. this document references [6], [7].
Another issue is the potential for catastrophic failures when a Another issue is the potential for catastrophic failures when a
single elliptic curve is widely used. In this case, an attack on the single elliptic curve is widely used. In this case, an attack on the
elliptic curve might result in the compromise of a large number of elliptic curve might result in the compromise of a large number of
keys. Again, this concern may need to be balanced against efficiency keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely-used curves. and interoperability improvements associated with widely-used curves.
Substantial additional information on elliptic curve choice can be Substantial additional information on elliptic curve choice can be
found in [4], [5], [6], [8]. found in [5], [6], [7], [9].
Implementors and users must also consider whether they need forward Implementors and users must also consider whether they need forward
secrecy. Forward secrecy refers to the property that session keys secrecy. Forward secrecy refers to the property that session keys
are not compromised if the static, certified keys belonging to the are not compromised if the static, certified keys belonging to the
server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key server and client are compromised. The ECDHE_ECDSA and ECDHE_RSA key
exchange algorithms provide forward secrecy protection in the event exchange algorithms provide forward secrecy protection in the event
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
skipping to change at page 31, line 19 skipping to change at page 33, line 19
o NamedCurve (Section 5.1) o NamedCurve (Section 5.1)
o ECPointFormat (Section 5.1) o ECPointFormat (Section 5.1)
o ECCurveType (Section 5.4) o ECCurveType (Section 5.4)
For each name space, this document defines the initial value For each name space, this document defines the initial value
assignments and defines a range of 256 values (NamedCurve) or eight assignments and defines a range of 256 values (NamedCurve) or eight
values (ECPointFormat and ECCurveType) reserved for Private Use. Any values (ECPointFormat and ECCurveType) reserved for Private Use. Any
additional assignments require IETF Consensus action [12]. additional assignments require IETF Consensus action [14].
[[ EDITOR: This documents also contains assignments to the registry
for TLS ciphersuites defined in [4], and to the TLS Cipher Suite
Registry and the TLS ClientCertificateType Identifiers Registry
defined in [3]. All of these are currently marked as tentative since
final assignments will have to be by IANA; see "EDITOR" notes in
Section 5.1 (and Section 5.1.1 and Section 5.1.1), Section 5.5, and
Section 6. ]]
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Bill Anderson and Tim Dierks. The authors wish to thank Bill Anderson and Tim Dierks.
10. References 10. References
10.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] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1",
draft-ietf-tls-rfc2246bis-13.txt (work in progress), June 2005.
[[ EDITOR: The cited Internet-Draft has been approved by the
IESG; the citation will have to be changed once it has been
published as RFC. ]]
[4] 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-02.txt (work in progress),
September 2005.
[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, [[ EDITOR: The cited Internet-Draft has been approved by the
IESG; the citation will have to be changed once it has been
published as RFC. ]]
[5] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>. <http://www.secg.org/>.
[5] IEEE, "Standard Specifications for Public Key Cryptography", [6] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000. IEEE 1363, 2000.
[6] ANSI, "Public Key Cryptography For The Financial Services [7] ANSI, "Public Key Cryptography For The Financial Services
Industry: The Elliptic Curve Digital Signature Algorithm Industry: The Elliptic Curve Digital Signature Algorithm
(ECDSA)", ANSI X9.62, 1998. (ECDSA)", ANSI X9.62, 1998.
[7] NIST, "Secure Hash Standard", FIPS 180-2, 2002. [8] NIST, "Secure Hash Standard", FIPS 180-2, 2002.
[8] NIST, "Digital Signature Standard", FIPS 186-2, 2000. [9] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[9] RSA Laboratories, "PKCS#1: RSA Encryption Standard version [10] RSA Laboratories, "PKCS#1: RSA Encryption Standard version
1.5", PKCS 1, November 1993. 1.5", PKCS 1, November 1993.
[10] SECG, "Recommended Elliptic Curve Domain Parameters", SEC 2, [11] 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 [12] 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.
[12] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [13] Housley, R., Polk, T., Ford, W., and D. Solo, "Internet X.509
Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile", RFC 3280, April 2002.
[14] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 2434, October 1998. Considerations Section in RFCs", RFC 2434, October 1998.
10.2 Informative References 10.2 Informative References
[13] Harper, G., Menezes, A., and S. Vanstone, "Public-Key [15] 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.
[14] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key [16] 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/>.
[15] Freier, A., Karlton, P., and P. Kocher, "The SSL Protocol [17] 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>.
[16] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for [18] 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
Simon Blake-Wilson
Basic Commerce & Industries, Inc.
96 Spandia Ave
Unit 606
Toronto, ON M6G 2T6
CA
Phone: +1 416 214 5961
Email: sblakewilson@bcisse.com
Nelson Bolyard
Sun
Email: nelson@bolyard.com
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
Phone: +1 650 786 7551 Phone: +1 650 786 7551
Email: vipul.gupta@sun.com Email: vipul.gupta@sun.com
Simon Blake-Wilson Chris Hawk
Basic Commerce & Industries, Inc. Corriente Networks LLC
96 Spandia Ave 1563 Solano Ave., #484
Unit 606 Berkeley, CA 94707
Toronto, ON M6G 2T6 US
CA
Phone: +1 416 214 5961 Phone: +1 510 527 0601
Email: sblakewilson@bcisse.com Email: chris@corriente.net
Bodo Moeller Bodo Moeller
University of Calgary University of Calgary
Dept of Math & Stats Dept of Math & Stats
2500 University Dr NW 2500 University Dr NW
Calgary, AB T2N 1N4 Calgary, AB T2N 1N4
CA CA
Phone: +1 403 220 5735 Phone: +1 403 220 5735
Email: bodo@openssl.org Email: bodo@openssl.org
Chris Hawk
Corriente Networks
Email: chris@corriente.net
Nelson Bolyard
Email: nelson@bolyard.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
 End of changes. 101 change blocks. 
259 lines changed or deleted 321 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/