5349
INFORMATIONAL
Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Authors: L. Zhu, K. Jaganathan, K. Lauter
Date: September 2008
Area: sec
Working Group: krb-wg
Stream: IETF
Abstract
This document describes the use of Elliptic Curve certificates, Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman (ECDH) key agreement within the framework of PKINIT -- the Kerberos Version 5 extension that provides for the use of public key cryptography. This memo provides information for the Internet community.
RFC 5349
INFORMATIONAL
Network Working Group L. Zhu
Request for Comments: 5349 K. Jaganathan
Category: Informational K. Lauter
Microsoft Corporation
September 2008
<span class="h1">Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography</span>
<span class="h1">for Initial Authentication in Kerberos (PKINIT)</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Abstract
This document describes the use of Elliptic Curve certificates,
Elliptic Curve signature schemes and Elliptic Curve Diffie-Hellman
(ECDH) key agreement within the framework of PKINIT -- the Kerberos
Version 5 extension that provides for the use of public key
cryptography.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Conventions Used in This Document . . . . . . . . . . . . . . . <a href="#page-2">2</a>
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-4">4</a>. Using the ECDH Key Exchange . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-5">5</a>. Choosing the Domain Parameters and the Key Size . . . . . . . . <a href="#page-4">4</a>
<a href="#section-6">6</a>. Interoperability Requirements . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-7">7</a>. Security Considerations . . . . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<span class="grey">Zhu, et al. Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
Elliptic Curve Cryptography (ECC) is emerging as an attractive
public-key cryptosystem that provides security equivalent to
currently popular public-key mechanisms such as RSA and DSA with
smaller key sizes [<a href="#ref-LENSTRA" title=""Selecting Cryptographic Key Sizes"">LENSTRA</a>] [<a href="#ref-NISTSP80057" title=""Recommendation on Key Management"">NISTSP80057</a>].
Currently, [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>] permits the use of ECC algorithms but it does
not specify how ECC parameters are chosen or how to derive the shared
key for key delivery using Elliptic Curve Diffie-Hellman (ECDH)
[<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>] [<a href="#ref-X9.63" title=""Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography"">X9.63</a>].
This document describes how to use Elliptic Curve certificates,
Elliptic Curve signature schemes, and ECDH with [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>]. However,
it should be noted that there is no syntactic or semantic change to
the existing [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>] messages. Both the client and the Key
Distribution Center (KDC) contribute one ECDH key pair using the key
agreement protocol described in this document.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Using Elliptic Curve Certificates and Elliptic Curve Signature</span>
<span class="h2"> Schemes</span>
ECC certificates and signature schemes can be used in the
Cryptographic Message Syntax (CMS) [<a href="./rfc3852" title=""Cryptographic Message Syntax (CMS)"">RFC3852</a>] [<a href="./rfc3278" title=""Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)"">RFC3278</a>] content type
'SignedData'.
X.509 certificates [<a href="./rfc5280" title=""Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC5280</a>] that contain ECC public keys or are
signed using ECC signature schemes MUST comply with [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>].
The signatureAlgorithm field of the CMS data type 'SignerInfo' can
contain one of the following ECC signature algorithm identifiers:
ecdsa-with-Sha1 [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>]
ecdsa-with-Sha256 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
ecdsa-with-Sha384 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
ecdsa-with-Sha512 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
The corresponding digestAlgorithm field contains one of the following
hash algorithm identifiers respectively:
<span class="grey">Zhu, et al. Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
id-sha1 [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>]
id-sha256 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
id-sha384 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
id-sha512 [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>]
Namely, id-sha1 MUST be used in conjunction with ecdsa-with-Sha1,
id-sha256 MUST be used in conjunction with ecdsa-with-Sha256,
id-sha384 MUST be used in conjunction with ecdsa-with-Sha384, and
id-sha512 MUST be used in conjunction with ecdsa-with-Sha512.
Implementations of this specification MUST support ecdsa-with-Sha256
and SHOULD support ecdsa-with-Sha1.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Using the ECDH Key Exchange</span>
This section describes how ECDH can be used as the Authentication
Service (AS) reply key delivery method [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>]. Note that the
protocol description here is similar to that of Modular Exponential
Diffie-Hellman (MODP DH), as described in [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>].
If the client wishes to use the ECDH key agreement method, it encodes
its ECDH public key value and the key's domain parameters [<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>]
[<a href="#ref-X9.63" title=""Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography"">X9.63</a>] in clientPublicValue of the PA-PK-AS-REQ message [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>].
As described in [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>], the ECDH domain parameters for the
client's public key are specified in the algorithm field of the type
SubjectPublicKeyInfo [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>] and the client's ECDH public key value
is mapped to a subjectPublicKey (a BIT STRING) according to
[<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>].
The following algorithm identifier is used to identify the client's
choice of the ECDH key agreement method for key delivery.
id-ecPublicKey (Elliptic Curve Diffie-Hellman [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>])
If the domain parameters are not accepted by the KDC, the KDC sends
back an error message [<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>] with the code
KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>]. This error message
contains the list of domain parameters acceptable to the KDC. This
list is encoded as TD-DH-PARAMETERS [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>], and it is in the KDC's
decreasing preference order. The client can then pick a set of
domain parameters from the list and retry the authentication.
Both the client and the KDC MUST have local policy that specifies
which set of domain parameters are acceptable if they do not have a
priori knowledge of the chosen domain parameters. The need for such
local policy is explained in <a href="#section-7">Section 7</a>.
<span class="grey">Zhu, et al. Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
If the ECDH domain parameters are accepted by the KDC, the KDC sends
back its ECDH public key value in the subjectPublicKey field of the
PA-PK-AS-REP message [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>].
As described in [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>], the KDC's ECDH public key value is encoded
as a BIT STRING according to [<a href="./rfc3279" title=""Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"">RFC3279</a>].
Note that in the steps above, the client can indicate to the KDC that
it wishes to reuse ECDH keys or it can allow the KDC to do so, by
including the clientDHNonce field in the request [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>]; the KDC
can then reuse the ECDH keys and include the serverDHNonce field in
the reply [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>]. This logic is the same as that of the Modular
Exponential Diffie-Hellman key agreement method [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>].
If ECDH is negotiated as the key delivery method, then the
PA-PK-AS-REP and AS reply key are generated as in <a href="./rfc4556#section-3.2.3.1">Section 3.2.3.1 of
[RFC4556]</a> with the following difference: The ECDH shared secret value
(an elliptic curve point) is calculated using operation ECSVDP-DH as
described in Section 7.2.1 of [<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>]. The x-coordinate of this
point is converted to an octet string using operation FE2OSP as
described in Section 5.5.4 of [<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>]. This octet string is the
DHSharedSecret.
Both the client and KDC then proceed as described in [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>] and
[<a href="./rfc4120" title=""The Kerberos Network Authentication Service (V5)"">RFC4120</a>].
Lastly, it should be noted that ECDH can be used with any
certificates and signature schemes. However, a significant advantage
of using ECDH together with ECC certificates and signature schemes is
that the ECC domain parameters in the client certificates or the KDC
certificates can be used. This obviates the need of locally
preconfigured domain parameters as described in <a href="#section-7">Section 7</a>.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Choosing the Domain Parameters and the Key Size</span>
The domain parameters and the key size should be chosen so as to
provide sufficient cryptographic security [<a href="./rfc3766" title=""Determining Strengths For Public Keys Used For Exchanging Symmetric Keys"">RFC3766</a>]. The following
table, based on table 2 on page 63 of NIST SP800-57 part 1
[<a href="#ref-NISTSP80057" title=""Recommendation on Key Management"">NISTSP80057</a>], gives approximate comparable key sizes for symmetric-
and asymmetric-key cryptosystems based on the best-known algorithms
for attacking them.
<span class="grey">Zhu, et al. Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
Symmetric | ECC | RSA
-------------+----------- +------------
80 | 160 - 223 | 1024
112 | 224 - 255 | 2048
128 | 256 - 383 | 3072
192 | 384 - 511 | 7680
256 | 512+ | 15360
Table 1: Comparable key sizes (in bits)
Thus, for example, when securing a 128-bit symmetric key, it is
prudent to use 256-bit Elliptic Curve Cryptography (ECC), e.g., group
P-256 (secp256r1) as described below.
A set of ECDH domain parameters is also known as a "curve". A curve
is a "named curve" if the domain parameters are well known and can be
identified by an Object Identifier; otherwise, it is called a "custom
curve". [<a href="./rfc4556" title=""Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)"">RFC4556</a>] supports both named curves and custom curves, see
<a href="#section-7">Section 7</a> on the tradeoffs of choosing between named curves and
custom curves.
The named curves recommended in this document are also recommended by
the National Institute of Standards and Technology (NIST)[<a href="#ref-FIPS186-2" title=""Digital Signature Standard"">FIPS186-2</a>].
These fifteen ECC curves are given in the following table [<a href="#ref-FIPS186-2" title=""Digital Signature Standard"">FIPS186-2</a>]
[<a href="#ref-SEC2" title=""SEC 2 - Recommended Elliptic Curve Domain Parameters"">SEC2</a>].
Description SEC 2 OID
----------------- ---------
ECPRGF192Random group P-192 secp192r1
EC2NGF163Random group B-163 sect163r2
EC2NGF163Koblitz group K-163 sect163k1
ECPRGF224Random group P-224 secp224r1
EC2NGF233Random group B-233 sect233r1
EC2NGF233Koblitz group K-233 sect233k1
ECPRGF256Random group P-256 secp256r1
EC2NGF283Random group B-283 sect283r1
EC2NGF283Koblitz group K-283 sect283k1
ECPRGF384Random group P-384 secp384r1
EC2NGF409Random group B-409 sect409r1
EC2NGF409Koblitz group K-409 sect409k1
ECPRGF521Random group P-521 secp521r1
EC2NGF571Random group B-571 sect571r1
EC2NGF571Koblitz group K-571 sect571k1
<span class="grey">Zhu, et al. Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Interoperability Requirements</span>
Implementations conforming to this specification MUST support curve
P-256 and P-384.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Security Considerations</span>
When using ECDH key agreement, the recipient of an elliptic curve
public key should perform the checks described in IEEE P1363, Section
A16.10 [<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>]. It is especially important, if the recipient is
using a long-term ECDH private key, to check that the sender's public
key is a valid point on the correct elliptic curve; otherwise,
information may be leaked about the recipient's private key, and
iterating the attack will eventually completely expose the
recipient's private key.
Kerberos error messages are not integrity protected; as a result, the
domain parameters sent by the KDC as TD-DH-PARAMETERS can be tampered
with by an attacker so that the set of domain parameters selected
could be either weaker or not mutually preferred. Local policy can
configure sets of domain parameters that are acceptable locally or
can disallow the negotiation of ECDH domain parameters.
Beyond elliptic curve size, the main issue is elliptic curve
structure. As a general principle, it is more conservative to use
elliptic curves with as little algebraic structure as possible.
Thus, random curves are more conservative than special curves (such
as Koblitz curves), and curves over F_p with p random are more
conservative than curves over F_p with p of a special form. (Also,
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
of similar size for characteristic 2.) Note, however, that algebraic
structure can also lead to implementation efficiencies, and
implementors and users may, therefore, need to balance conservatism
against a need for efficiency. Concrete attacks are known against
only very few special classes of curves, such as supersingular
curves, and these classes are excluded from the ECC standards such as
[<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>] and [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>].
Another issue is the potential for catastrophic failures when a
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
keys. Again, this concern may need to be balanced against efficiency
and interoperability improvements associated with widely used curves.
Substantial additional information on elliptic curve choice can be
found in [<a href="#ref-IEEE1363" title=""Standard Specifications for Public Key Cryptography"">IEEE1363</a>], [<a href="#ref-X9.62" title=""Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)"">X9.62</a>], and [<a href="#ref-FIPS186-2" title=""Digital Signature Standard"">FIPS186-2</a>].
<span class="grey">Zhu, et al. Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
The following people have made significant contributions to this
document: Paul Leach, Dan Simon, Kelvin Yiu, David Cross, Sam
Hartman, Tolga Acar, and Stefan Santesson.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-FIPS186-2">FIPS186-2</a>] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[<a id="ref-IEEE1363">IEEE1363</a>] IEEE, "Standard Specifications for Public Key
Cryptography", IEEE 1363, 2000.
[<a id="ref-NISTSP80057">NISTSP80057</a>] NIST, "Recommendation on Key Management", SP 800-57,
August 2005,
<<a href="http://csrc.nist.gov/publications/nistpubs/">http://csrc.nist.gov/publications/nistpubs/</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3278">RFC3278</a>] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of
Elliptic Curve Cryptography (ECC) Algorithms in
Cryptographic Message Syntax (CMS)", <a href="./rfc3278">RFC 3278</a>,
April 2002.
[<a id="ref-RFC3279">RFC3279</a>] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", <a href="./rfc3279">RFC 3279</a>, April 2002.
[<a id="ref-RFC3766">RFC3766</a>] Orman, H. and P. Hoffman, "Determining Strengths For
Public Keys Used For Exchanging Symmetric Keys",
<a href="https://www.rfc-editor.org/bcp/bcp86">BCP 86</a>, <a href="./rfc3766">RFC 3766</a>, April 2004.
[<a id="ref-RFC3852">RFC3852</a>] Housley, R., "Cryptographic Message Syntax (CMS)",
<a href="./rfc3852">RFC 3852</a>, July 2004.
[<a id="ref-RFC4120">RFC4120</a>] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)",
<a href="./rfc4120">RFC 4120</a>, July 2005.
[<a id="ref-RFC4556">RFC4556</a>] Zhu, L. and B. Tung, "Public Key Cryptography for
Initial Authentication in Kerberos (PKINIT)",
<a href="./rfc4556">RFC 4556</a>, June 2006.
<span class="grey">Zhu, et al. Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
[<a id="ref-RFC5280">RFC5280</a>] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", <a href="./rfc5280">RFC 5280</a>, May 2008.
[<a id="ref-X9.62">X9.62</a>] ANSI, "Public Key Cryptography For The Financial
Services Industry: The Elliptic Curve Digital
Signature Algorithm (ECDSA)", ANSI X9.62, 2005.
[<a id="ref-X9.63">X9.63</a>] ANSI, "Public Key Cryptography for the Financial
Services Industry: Key Agreement and Key Transport
using Elliptic Curve Cryptography", ANSI X9.63, 2001.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-LENSTRA">LENSTRA</a>] Lenstra, A. and E. Verheul, "Selecting Cryptographic
Key Sizes", Journal of Cryptography 14, 255-293, 2001.
[<a id="ref-SEC2">SEC2</a>] Standards for Efficient Cryptography Group, "SEC 2 -
Recommended Elliptic Curve Domain Parameters",
Ver. 1.0, 2000, <<a href="http://www.secg.org">http://www.secg.org</a>>.
<span class="grey">Zhu, et al. Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
Authors' Addresses
Larry Zhu
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: [email protected]
Karthik Jaganathan
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: [email protected]
Kristin Lauter
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
US
EMail: [email protected]
<span class="grey">Zhu, et al. Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc5349">RFC 5349</a> ECC Support for PKINIT September 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
[email protected].
Zhu, et al. Informational [Page 10]
Annotations
Select text to annotate