< draft-ietf-tls-ecc-09.txt   draft-ietf-tls-ecc-10.txt >
TLS Working Group V. Gupta TLS Working Group V. Gupta
Internet-Draft Sun Labs Internet-Draft Sun Labs
Expires: October 9, 2005 S. Blake-Wilson Expires: December 2, 2005 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
April 7, 2005 May 31, 2005
ECC Cipher Suites for TLS ECC Cipher Suites for TLS
<draft-ietf-tls-ecc-09.txt> <draft-ietf-tls-ecc-10.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of Section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 October 9, 2005. This Internet-Draft will expire on December 2, 2005.
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", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
skipping to change at page 7, line 16 skipping to change at page 7, line 16
2.1 ECDH_ECDSA 2.1 ECDH_ECDSA
In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable
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 MUST generate 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 Section 3.2 or Section 3.3 apply).
Both client and server MUST 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 MUST send its ephemeral ECDH public key and a The server sends its ephemeral ECDH public key and a specification of
specification of the corresponding curve in the ServerKeyExchange the corresponding curve in the ServerKeyExchange message. These
message. These parameters MUST be signed with ECDSA using the parameters MUST be signed with ECDSA using the private key
private key corresponding to the public key in the server's corresponding to the public key in the server's Certificate.
Certificate.
The client MUST generate 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 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 MUST perform an ECDH operation (Section 5.10) Both client and server perform an ECDH operation (Section 5.10) and
and use the resultant shared secret as the premaster secret. use the resultant shared secret as the premaster secret.
2.3 ECDH_RSA 2.3 ECDH_RSA
This key exchange algorithm is the same as ECDH_ECDSA except the This key exchange algorithm is the same as ECDH_ECDSA except the
server's certificate MUST be signed with RSA rather than ECDSA. server's certificate MUST be signed with RSA rather than ECDSA.
2.4 ECDHE_RSA 2.4 ECDHE_RSA
This key exchange algorithm is the same as ECDHE_ECDSA except the This key exchange algorithm is the same as ECDHE_ECDSA except the
server's certificate MUST contain an RSA public key authorized for server's certificate MUST contain an RSA public key authorized for
signing and the signature in the ServerKeyExchange message MUST be signing and the signature in the ServerKeyExchange message must be
computed with the corresponding RSA private key. The server computed with the corresponding RSA private key. The server
certificate MUST be signed with RSA. certificate MUST be signed with RSA.
2.5 ECDH_anon 2.5 ECDH_anon
In ECDH_anon, the server's Certificate, the CertificateRequest, the In ECDH_anon, the server's Certificate, the CertificateRequest, the
client's Certificate, and the CertificateVerify messages MUST NOT be client's Certificate, and the CertificateVerify messages MUST NOT be
sent. sent.
The server MUST send an ephemeral ECDH public key and a specification The server MUST send an ephemeral ECDH public key and a specification
of the corresponding curve in the ServerKeyExchange message. These of the corresponding curve in the ServerKeyExchange message. These
parameters MUST NOT be signed. parameters MUST NOT be signed.
The client MUST generate 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 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 MUST 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
key exchange algorithms require the server's certificate to be signed
with a particular signature scheme, this specification (following the
similar cases DH_DSS, DHE_DSS, DH_RSA, and DHE_RSA in [2]) does not
impose restrictions on signature schemes used elsewhere in the
certificate chain. (Often such restrictions will be useful, and it
is expected that this will be taken into account in certification
authorities' signing practices. However, such restrictions are not
strictly required in general: Even if it is beyond the capabilities
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
anchor that appears as one of the 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]. 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
methods suggested by the server and is willing to use it for methods suggested by the server and is willing to use it for
authentication. authentication.
If these conditions are not met, the client should send a client If these conditions are not met, the client should send a client
Certificate message containing no certificates. In this case, the Certificate message containing no certificates. In this case, the
ClientKeyExchange should be sent as described in Section 2 and the ClientKeyExchange should be sent as described in Section 2 and the
CertificateVerify should not be sent. If the server requires client CertificateVerify should not be sent. If the server requires client
authentication, it may respond with a fatal handshake failure alert. authentication, it may respond with a fatal handshake failure alert.
If the client has an appropriate certificate and is willing to use it If the client has an appropriate certificate and is willing to use it
for authentication, it MUST send that certificate in the client's for authentication, it must send that certificate in the client's
Certificate message (as per Section 5.6) and prove possession of the Certificate message (as per Section 5.6) and prove possession of the
private key corresponding to the certified key. The process of private key corresponding to the certified key. The process of
determining an appropriate certificate and proving possession is determining an appropriate certificate and proving possession is
different for each authentication mechanism and described below. different for each authentication mechanism and described below.
NOTE: It is permissible for a server to request (and the client to NOTE: It is permissible for a server to request (and the client to
send) a client certificate of a different type than the server send) a client certificate of a different type than the server
certificate. certificate.
3.1 ECDSA_sign 3.1 ECDSA_sign
To use this authentication mechanism, the client MUST possess a To use this authentication mechanism, the client MUST possess a
certificate containing an ECDSA-capable public key and signed with certificate containing an ECDSA-capable public key and signed with
ECDSA. ECDSA.
The client MUST prove possession of the private key corresponding to The client proves possession of the private key corresponding to the
the certified key by including a signature in the CertificateVerify certified key by including a signature in the CertificateVerify
message as described in Section 5.8. message as described in Section 5.8.
3.2 ECDSA_fixed_ECDH 3.2 ECDSA_fixed_ECDH
To use this authentication mechanism, the client MUST possess a To use this authentication mechanism, the client MUST possess a
certificate containing an ECDH-capable public key and that certificate containing an ECDH-capable public key and that
certificate MUST be signed with ECDSA. Furthermore, the client's certificate MUST be signed with ECDSA. Furthermore, the client's
ECDH key MUST be on the same elliptic curve as the server's long-term ECDH key MUST be on the same elliptic curve as the server's long-term
(certified) ECDH key. This might limit use of this mechanism to (certified) ECDH key. This might limit use of this mechanism to
closed environments. In situations where the client has an ECC key closed environments. In situations where the client has an ECC key
skipping to change at page 11, line 5 skipping to change at page 10, line 33
client's ability to arrive at the same premaster secret as the server client's ability to arrive at the same premaster secret as the server
(demonstrated by a successful exchange of Finished messages) proves (demonstrated by a successful exchange of Finished messages) proves
possession of the private key corresponding to the certified public possession of the private key corresponding to the certified public
key and the CertificateVerify message is unnecessary. key and the CertificateVerify message is unnecessary.
3.3 RSA_fixed_ECDH 3.3 RSA_fixed_ECDH
This authentication mechanism is identical to ECDSA_fixed_ECDH except This authentication mechanism is identical to ECDSA_fixed_ECDH except
the client's certificate MUST be signed with RSA. the client's certificate MUST be signed with RSA.
Note that while the ECDSA_sign, ECDSA_fixed_ECDH, and RSA_fixed_ECDH
client authentication mechanisms require the clients's certificate to
be signed with a particular signature scheme, this specification does
not impose restrictions on signature schemes used elsewhere in the
certificate chain. (Often such restrictions will be useful, and it
is expected that this will be taken into account in certification
authorities' signing practices. However, such restrictions are not
strictly required in general: Even if it is beyond the capabilities
of a server to completely validate a given chain, the server may be
able to validate the clients certificate by relying on a trust anchor
that appears as one of the intermediate certificates in the chain.)
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 [3]; message details are
skipping to change at page 14, line 7 skipping to change at page 14, line 7
the following octets: the following octets:
00 ?? 00 03 02 13 15 00 ?? 00 03 02 13 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 254 = 0xFE) would include an extension consisting of the
following octets: following octets:
00 ?? 00 02 01 FE 00 ?? 00 02 01 FE
enum { uncompressed (0), ansiX962_compressed (1), enum { uncompressed (0), ansiX962_compressed_prime (1),
ansiX962_hybrid (2), reserved (3 .. 255) ansiX962_compressed_char2 (2), reserved (3 .. 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. The implementations of this document MUST support it for all of their
ansiX962_compressed format reduces bandwidth by including only the supported curves. Compressed point formats reduce bandwidth by
x-coordinate and a single bit of the y-coordinate of the point. The including only the x-coordinate and a single bit of the y-coordinate
ansiX962_hybrid format includes both the full y-coordinate and the of the point. Implementations of this document MAY support the
compressed y-coordinate to allow flexibility and improve efficiency ansiX962_compressed_prime and ansiX962_compressed_char2 formats,
in some cases. Implementations of this document MAY support the where the former applies only to prime curves and the latter applies
ansiX962_compressed and ansiX962_hybrid point formats. (These three only to characteristic-2 curves. (All formats are described in [6].)
formats are described in [6].) Values 248 through 255 are reserved Values 248 through 255 are reserved for private use.
for private use.
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 includes A client that can parse only the uncompressed point format (value 0)
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 prefers the use of the ansiX962_compressed format over A client that in the case of prime fields prefers the compressed
uncompressed may indicate that preference by including an extension format (ansiX962_compressed_prime, value 1) over the uncompressed
consisting of the following octets: format (value 0), but in the case of characteristic-2 fields prefers
the uncompressed format (value 0) over the compressed format
(ansiX962_compressed_char2, value 2), may indicate these preferences
by including an extension consisting of the following octets:
00 ?? 00 03 02 01 00 00 ?? 00 04 03 01 00 02
Actions of the sender: Actions of the sender:
A client that proposes ECC cipher suites in its ClientHello message A client that proposes ECC cipher suites in its ClientHello message
appends these extensions (along with any others), enumerating the appends these extensions (along with any others), enumerating the
curves it supports and the point formats it can parse. Clients curves it supports and the point formats it can parse. Clients
SHOULD send both the Supported Elliptic Curves Extension and the SHOULD send both the Supported Elliptic Curves Extension and the
Supported Point Formats Extension. If the Supported Point Formats Supported Point Formats Extension. If the Supported Point Formats
Extension is indeed sent, it MUST contain the value 0 (uncompressed) Extension is indeed sent, it MUST contain the value 0 (uncompressed)
as one of the items in the list of point formats. as one of the items in the list of point formats.
skipping to change at page 19, line 8 skipping to change at page 19, line 8
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].
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 [6]. This byte string may represent an elliptic curve point
in uncompressed, hybrid, or compressed format; it MUST conform to in uncompressed, or compressed format; it MUST conform to what the
what the client has requested through a Supported Point Formats client has requested through a Supported Point Formats Extension
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
field using a pentanomial basis. field using a pentanomial basis.
struct { struct {
skipping to change at page 23, line 36 skipping to change at page 23, line 36
must be encoded in certificates as described in Section 5.9. must be encoded in certificates as described in Section 5.9.
NOTE: The client's Certificate message is capable of carrying a chain NOTE: The client's Certificate message is capable of carrying a chain
of certificates. The restrictions mentioned in Table 4 apply only to of certificates. The restrictions mentioned in Table 4 apply only to
the client's certificate (first in the chain). the client's certificate (first in the chain).
Client Client
Authentication Method Client Certificate Type Authentication Method Client Certificate Type
--------------------- ----------------------- --------------------- -----------------------
ECDSA_sign Certificate must contain an ECDSA_sign Certificate MUST contain an
ECDSA-capable public key and ECDSA-capable public key and
be signed with ECDSA. be signed with ECDSA.
ECDSA_fixed_ECDH Certificate must contain an ECDSA_fixed_ECDH Certificate MUST contain an
ECDH-capable public key on the ECDH-capable public key on the
same elliptic curve as the server's same elliptic curve as the server's
long-term ECDH key. This certificate long-term ECDH key. This certificate
must be signed with ECDSA. MUST be signed with ECDSA.
RSA_fixed_ECDH Certificate must contain an RSA_fixed_ECDH Certificate MUST contain an
ECDH-capable public key on the ECDH-capable public key on the
same elliptic curve as the server's same elliptic curve as the server's
long-term ECDH key. This certificate long-term ECDH key. This certificate
must be signed with RSA. MUST be signed with RSA.
Table 4: Client certificate types Table 4: Client certificate types
Structure of this message: Structure of this message:
Identical to the TLS client Certificate format. Identical to the TLS client Certificate format.
Actions of the sender: Actions of the sender:
The client constructs an appropriate certificate chain, and conveys The client constructs an appropriate certificate chain, and conveys
skipping to change at page 25, line 13 skipping to change at page 25, line 13
mechanism.) mechanism.)
struct { struct {
select (PublicValueEncoding) { select (PublicValueEncoding) {
case implicit: struct { }; case implicit: struct { };
case explicit: ECPoint ecdh_Yc; case explicit: ECPoint ecdh_Yc;
} ecdh_public; } ecdh_public;
} ClientECDiffieHellmanPublic; } ClientECDiffieHellmanPublic;
ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte ecdh_Yc: Contains the client's ephemeral ECDH public key as a byte
string ECPoint.point, which may represent an elliptic curve point string ECPoint.point, which may represent an elliptic curve point
in uncompressed, hybrid, or compressed format. Here the format in uncompressed or compressed format. Here the format MUST
MUST conform to what the server has requested through a Supported conform to what the server has requested through a Supported Point
Point Formats Extension if this extension was used, and MUST be Formats Extension if this extension was used, and MUST be
uncompressed if this extension was not used. uncompressed if this extension was not used.
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:
skipping to change at page 26, line 52 skipping to change at page 26, line 52
5.9 Elliptic Curve Certificates 5.9 Elliptic Curve Certificates
X509 certificates containing ECC public keys or signed using ECDSA X509 certificates containing ECC public keys or signed using ECDSA
MUST comply with [11] or another RFC that replaces or extends it. MUST comply with [11] 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 [6], FIPS 186-2 [8], and SEC 2 [10].
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) MUST be performed according to [5] as the shared secret calculation) are performed according to [5]
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, so that the premaster secret is the x-coordinate of the
ECDH shared secret elliptic curve point, i.e. the octet string Z in ECDH shared secret elliptic curve point represented as an octet
IEEE 1363 terminology. string. Note that this octet string (Z in IEEE 1363 terminology) as
output by FE2OSP, the Field Element to Octet String Conversion
Primitive, has constant length for any given field; leading zeros
found in this octet string MUST NOT be truncated.
Note that a new extension may be introduced in the future to allow Note that a new extension may be introduced in the future to allow
the use of a different KDF during computation of the premaster the use of a different KDF during computation of the premaster
secret. In this event, the new KDF would be used in place of the secret. In this event, the new KDF would be used in place of the
process detailed above. This may be desirable, for example, to process detailed above. This may be desirable, for example, to
support compatibility with the planned NIST key agreement standard. support compatibility with the planned NIST key agreement standard.
All ECDSA computations MUST be performed according to ANSI X9.62 [6] All ECDSA computations MUST be performed according to ANSI X9.62 [6]
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
skipping to change at page 32, line 17 skipping to change at page 32, line 17
9.1 Normative References 9.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-00.txt (work in progress), Nov. 2004. draft-ietf-tls-rfc3546bis-01.txt (work in progress), May 2005.
[4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000, [4] SECG, "Elliptic Curve Cryptography", SEC 1, 2000,
<http://www.secg.org/>. <http://www.secg.org/>.
[5] IEEE, "Standard Specifications for Public Key Cryptography", [5] IEEE, "Standard Specifications for Public Key Cryptography",
IEEE 1363, 2000. IEEE 1363, 2000.
[6] ANSI, "Public Key Cryptography For The Financial Services [6] 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.
 End of changes. 34 change blocks. 
60 lines changed or deleted 89 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/