Network Working Group L. Zhu
Request for Comments: 5349 K. Jaganathan
Category: Informational K. Lauter
Microsoft Corporation
September 2008
Network Working Group L. Zhu
Request for Comments: 5349 K. Jaganathan
Category: Informational K. Lauter
Microsoft Corporation
September 2008
Elliptic Curve Cryptography (ECC) Support for Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
椭圆曲线加密（ECC）支持Kerberos（PKINIT）中用于初始身份验证的公钥加密
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.
本文档描述了在PKINIT框架内椭圆曲线证书、椭圆曲线签名方案和椭圆曲线Diffie-Hellman（ECDH）密钥协议的使用，PKINIT是Kerberos版本5的扩展，提供了公钥密码的使用。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . 2
4. Using the ECDH Key Exchange . . . . . . . . . . . . . . . . . . 3
5. Choosing the Domain Parameters and the Key Size . . . . . . . . 4
6. Interoperability Requirements . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Using Elliptic Curve Certificates and Elliptic Curve
Signature Schemes . . . . . . . . . . . . . . . . . . . . . . . 2
4. Using the ECDH Key Exchange . . . . . . . . . . . . . . . . . . 3
5. Choosing the Domain Parameters and the Key Size . . . . . . . . 4
6. Interoperability Requirements . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
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 [LENSTRA] [NISTSP80057].
椭圆曲线密码（ECC）正在成为一种极具吸引力的公钥密码系统，它提供的安全性相当于目前流行的公钥机制，如RSA和DSA，密钥大小较小[LENSTRA][NISTSP80057]。
Currently, [RFC4556] 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) [IEEE1363] [X9.63].
目前，[RFC4556]允许使用ECC算法，但未指定如何选择ECC参数，或如何使用椭圆曲线Diffie-Hellman（ECDH）[IEEE1363][X9.63]推导用于密钥传递的共享密钥。
This document describes how to use Elliptic Curve certificates, Elliptic Curve signature schemes, and ECDH with [RFC4556]. However, it should be noted that there is no syntactic or semantic change to the existing [RFC4556] messages. Both the client and the Key Distribution Center (KDC) contribute one ECDH key pair using the key agreement protocol described in this document.
本文档描述了如何在[RFC4556]中使用椭圆曲线证书、椭圆曲线签名方案和ECDH。但是，应该注意的是，现有[RFC4556]消息没有语法或语义变化。客户端和密钥分发中心（KDC）都使用本文档中描述的密钥协议协议提供一个ECDH密钥对。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
3. Using Elliptic Curve Certificates and Elliptic Curve Signature Schemes
3. 使用椭圆曲线证书和椭圆曲线签名方案
ECC certificates and signature schemes can be used in the Cryptographic Message Syntax (CMS) [RFC3852] [RFC3278] content type 'SignedData'.
ECC证书和签名方案可用于加密消息语法（CMS）[RFC3852][RFC3278]内容类型“SignedData”。
X.509 certificates [RFC5280] that contain ECC public keys or are signed using ECC signature schemes MUST comply with [RFC3279].
包含ECC公钥或使用ECC签名方案签名的X.509证书[RFC5280]必须符合[RFC3279]。
The signatureAlgorithm field of the CMS data type 'SignerInfo' can contain one of the following ECC signature algorithm identifiers:
CMS数据类型“SignerInfo”的signatureAlgorithm字段可以包含以下ECC签名算法标识符之一：
ecdsa-with-Sha1 [RFC3279]
ecdsa-with-Sha256 [X9.62]
ecdsa-with-Sha384 [X9.62]
ecdsa-with-Sha512 [X9.62]
ecdsa-with-Sha1 [RFC3279]
ecdsa-with-Sha256 [X9.62]
ecdsa-with-Sha384 [X9.62]
ecdsa-with-Sha512 [X9.62]
The corresponding digestAlgorithm field contains one of the following hash algorithm identifiers respectively:
相应的digestAlgorithm字段分别包含以下哈希算法标识符之一：
id-sha1 [RFC3279]
id-sha256 [X9.62]
id-sha384 [X9.62]
id-sha512 [X9.62]
id-sha1 [RFC3279]
id-sha256 [X9.62]
id-sha384 [X9.62]
id-sha512 [X9.62]
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.
即，id-sha1必须与ecdsa-with-sha1结合使用，id-sha256必须与ecdsa-with-sha256结合使用，id-sha384必须与ecdsa-with-sha384结合使用，id-sha512必须与ecdsa-with-sha512结合使用。
Implementations of this specification MUST support ecdsa-with-Sha256 and SHOULD support ecdsa-with-Sha1.
本规范的实现必须支持ecdsa-with-Sha256，并应支持ecdsa-with-Sha1。
This section describes how ECDH can be used as the Authentication Service (AS) reply key delivery method [RFC4556]. Note that the protocol description here is similar to that of Modular Exponential Diffie-Hellman (MODP DH), as described in [RFC4556].
本节介绍如何将ECDH用作身份验证服务（as）应答密钥传递方法[RFC4556]。请注意，此处的协议描述类似于[RFC4556]中所述的模指数Diffie-Hellman（MODP DH）。
If the client wishes to use the ECDH key agreement method, it encodes its ECDH public key value and the key's domain parameters [IEEE1363] [X9.63] in clientPublicValue of the PA-PK-AS-REQ message [RFC4556].
如果客户希望使用ECDH密钥协商方法，则在PA-PK-AS-REQ消息[RFC4556]的clientPublicValue中对其ECDH公钥值和密钥的域参数[IEEE1363][X9.63]进行编码。
As described in [RFC4556], the ECDH domain parameters for the client's public key are specified in the algorithm field of the type SubjectPublicKeyInfo [RFC3279] and the client's ECDH public key value is mapped to a subjectPublicKey (a BIT STRING) according to [RFC3279].
如[RFC4556]所述，客户机公钥的ECDH域参数在SubjectPublicKeyInfo[RFC3279]类型的算法字段中指定，客户机的ECDH公钥值根据[RFC3279]映射到subjectPublicKey（位字符串）。
The following algorithm identifier is used to identify the client's choice of the ECDH key agreement method for key delivery.
以下算法标识符用于确定客户选择ECDH密钥协商方法进行密钥传递。
id-ecPublicKey (Elliptic Curve Diffie-Hellman [RFC3279])
id ecPublicKey（椭圆曲线Diffie-Hellman[RFC3279]）
If the domain parameters are not accepted by the KDC, the KDC sends back an error message [RFC4120] with the code KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED [RFC4556]. This error message contains the list of domain parameters acceptable to the KDC. This list is encoded as TD-DH-PARAMETERS [RFC4556], 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.
如果KDC不接受域参数，KDC将返回错误消息[RFC4120]，代码为KDC_ERR_DH_KEY_parameters_not_accepted[RFC4556]。此错误消息包含KDC可接受的域参数列表。该列表编码为TD-DH-PARAMETERS[RFC4556]，并按KDC的递减优先顺序排列。然后，客户端可以从列表中选择一组域参数并重试身份验证。
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 Section 7.
客户端和KDC都必须具有本地策略，该策略指定如果它们不具备所选域参数的先验知识，那么哪一组域参数是可接受的。第7节解释了此类当地政策的必要性。
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 [RFC4556].
如果KDC接受ECDH域参数，KDC将在PA-PK-AS-REP消息[RFC4556]的subjectPublicKey字段中发回其ECDH公钥值。
As described in [RFC4556], the KDC's ECDH public key value is encoded as a BIT STRING according to [RFC3279].
如[RFC4556]所述，KDC的ECDH公钥值根据[RFC3279]编码为位字符串。
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 [RFC4556]; the KDC can then reuse the ECDH keys and include the serverDHNonce field in the reply [RFC4556]. This logic is the same as that of the Modular Exponential Diffie-Hellman key agreement method [RFC4556].
注意，在上述步骤中，客户机可以向KDC指示它希望重用ECDH密钥，或者它可以允许KDC这样做，方法是在请求[RFC4556]中包含ClientDhnoce字段；然后，KDC可以重用ECDH密钥，并在回复[RFC4556]中包含serverDHNonce字段。该逻辑与模指数Diffie-Hellman密钥协商方法[RFC4556]的逻辑相同。
If ECDH is negotiated as the key delivery method, then the PA-PK-AS-REP and AS reply key are generated as in Section 3.2.3.1 of [RFC4556] 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 [IEEE1363]. The x-coordinate of this point is converted to an octet string using operation FE2OSP as described in Section 5.5.4 of [IEEE1363]. This octet string is the DHSharedSecret.
如果将ECDH协商为密钥传递方法，则按照[RFC4556]第3.2.3.1节生成PA-PK-as-REP和as-reply密钥，区别如下：ECDH共享秘密值（椭圆曲线点）使用[IEEE1363]第7.2.1节所述的操作ECSVDP-DH进行计算。如[IEEE1363]第5.5.4节所述，使用FE2OSP操作将该点的x坐标转换为八位组串。此八位字节字符串是DHSharedSecret。
Both the client and KDC then proceed as described in [RFC4556] and [RFC4120].
然后，客户机和KDC都按照[RFC4556]和[RFC4120]中所述进行。
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 Section 7.
最后，应该指出，ECDH可以与任何证书和签名方案一起使用。然而，将ECDH与ECC证书和签名方案一起使用的一个显著优点是可以使用客户端证书或KDC证书中的ECC域参数。这样就不需要第7节中描述的本地预配置域参数。
The domain parameters and the key size should be chosen so as to provide sufficient cryptographic security [RFC3766]. The following table, based on table 2 on page 63 of NIST SP800-57 part 1 [NISTSP80057], gives approximate comparable key sizes for symmetric-and asymmetric-key cryptosystems based on the best-known algorithms for attacking them.
应选择域参数和密钥大小，以便提供足够的加密安全性[RFC3766]。下表基于NIST SP800-57第1部分[NIST SP80057]第63页的表2，给出了基于最著名的攻击算法的对称和非对称密钥密码系统的近似可比密钥大小。
Symmetric | ECC | RSA
-------------+----------- +------------
80 | 160 - 223 | 1024
112 | 224 - 255 | 2048
128 | 256 - 383 | 3072
192 | 384 - 511 | 7680
256 | 512+ | 15360
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)
表1：可比密钥大小（以位为单位）
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.
因此，例如，当保护128位对称密钥时，谨慎地使用256位椭圆曲线密码（ECC），例如，组P-256（secp256r1），如下所述。
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". [RFC4556] supports both named curves and custom curves, see Section 7 on the tradeoffs of choosing between named curves and custom curves.
一组ECDH域参数也称为“曲线”。如果域参数是众所周知的，并且可以通过对象标识符识别，则曲线是“命名曲线”；否则，它被称为“自定义曲线”。[RFC4556]支持命名曲线和自定义曲线，请参阅第7节，了解在命名曲线和自定义曲线之间进行选择的权衡。
The named curves recommended in this document are also recommended by the National Institute of Standards and Technology (NIST)[FIPS186-2]. These fifteen ECC curves are given in the following table [FIPS186-2] [SEC2].
本文件中推荐的命名曲线也由国家标准与技术研究所（NIST）[FIPS186-2]推荐。下表[FIPS186-2][SEC2]给出了这15条ECC曲线。
Description SEC 2 OID
----------------- ---------
Description SEC 2 OID
----------------- ---------
ECPRGF192Random group P-192 secp192r1 EC2NGF163Random group B-163 sect163r2 EC2NGF163Koblitz group K-163 sect163k1
ECPRGF192随机群P-192 secp192r1 EC2NGF163随机群B-163扇区163R2 EC2NGF163KB斜群K-163扇区163K1
ECPRGF224Random group P-224 secp224r1 EC2NGF233Random group B-233 sect233r1 EC2NGF233Koblitz group K-233 sect233k1
ECPRGF224随机组P-224 SECP24R1 EC2NGF233随机组B-233扇区233R1 EC2NGF233 Koblitz组K-233扇区233K1
ECPRGF256Random group P-256 secp256r1 EC2NGF283Random group B-283 sect283r1 EC2NGF283Koblitz group K-283 sect283k1
ECPRGF256随机组P-256 secp256r1 EC2NGF283随机组B-283扇区283R1 EC2NGF283Koblitz组K-283扇区283K1
ECPRGF384Random group P-384 secp384r1 EC2NGF409Random group B-409 sect409r1 EC2NGF409Koblitz group K-409 sect409k1
ECPRGF384随机群P-384 secp384r1 EC2NGF409随机群B-409 sect409r1 EC2NGF409Koblitz群K-409 sect409k1
ECPRGF521Random group P-521 secp521r1 EC2NGF571Random group B-571 sect571r1 EC2NGF571Koblitz group K-571 sect571k1
ECPRGF521随机组P-521 secp521r1 EC2NGF571随机组B-571 sect571r1 EC2NGF571 Koblitz组K-571 sect571k1
Implementations conforming to this specification MUST support curve P-256 and P-384.
符合本规范的实施必须支持曲线P-256和P-384。
When using ECDH key agreement, the recipient of an elliptic curve public key should perform the checks described in IEEE P1363, Section A16.10 [IEEE1363]. 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.
使用ECDH密钥协议时，椭圆曲线公钥的接收方应执行IEEE P1363第A16.10节[IEEE1363]中所述的检查。特别重要的是，如果接收方使用的是长期ECDH私钥，则检查发送方的公钥是否是正确椭圆曲线上的有效点；否则，可能会泄露有关收件人私钥的信息，重复攻击最终将完全暴露收件人的私钥。
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.
Kerberos错误消息没有完整性保护；因此，KDC作为TD-DH-parameters发送的域参数可能会被攻击者篡改，因此所选域参数集可能较弱，或者不是双方都喜欢的。本地策略可以配置本地可接受或不允许协商ECDH域参数的域参数集。
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 [IEEE1363] and [X9.62].
除了椭圆曲线的大小，主要问题是椭圆曲线的结构。作为一般原则，使用代数结构尽可能少的椭圆曲线更为保守。因此，随机曲线比特殊曲线（如Koblitz曲线）更为保守，而F_p上带p随机的曲线比F_p上带p特殊形式的曲线更为保守。（此外，F_p上带有p random的曲线可能被认为比F_2^m上的曲线更保守，因为对于特征2，在多个大小相似的字段之间没有选择。）然而，请注意，代数结构也可以提高实现效率，因此，实现者和用户可能，需要平衡保守主义和效率的需要。已知的具体攻击仅针对极少数特殊类别的曲线，如超奇异曲线，这些类别被排除在ECC标准之外，如[IEEE1363]和[X9.62]。
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 [IEEE1363], [X9.62], and [FIPS186-2].
另一个问题是当一条椭圆曲线被广泛使用时，可能发生灾难性故障。在这种情况下，对椭圆曲线的攻击可能会导致大量密钥的泄露。同样，这一担忧可能需要与广泛使用的曲线相关的效率和互操作性改进相平衡。在[IEEE1363]、[X9.62]和[FIPS186-2]中可以找到关于椭圆曲线选择的大量其他信息。
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.
以下人士对本文件做出了重大贡献：保罗·利奇、丹·西蒙、凯文·姚、大卫·克罗斯、萨姆·哈特曼、托尔加·阿卡尔和斯特凡·桑特森。
[FIPS186-2] NIST, "Digital Signature Standard", FIPS 186-2, 2000.
[FIPS186-2]NIST，“数字签名标准”，FIPS186-22000。
[IEEE1363] IEEE, "Standard Specifications for Public Key Cryptography", IEEE 1363, 2000.
[IEEE1363]IEEE，“公钥加密的标准规范”，IEEE 1363，2000。
[NISTSP80057] NIST, "Recommendation on Key Management", SP 800-57, August 2005, <http://csrc.nist.gov/publications/nistpubs/>.
[NIST SP80057]NIST，“密钥管理建议”，SP 800-57，2005年8月<http://csrc.nist.gov/publications/nistpubs/>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3278] Blake-Wilson, S., Brown, D., and P. Lambert, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 3278, April 2002.
[RFC3278]Blake Wilson，S.，Brown，D.，和P.Lambert，“加密消息语法（CMS）中椭圆曲线加密（ECC）算法的使用”，RFC 3278，2002年4月。
[RFC3279] 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", RFC 3279, April 2002.
[RFC3279]Bassham，L.，Polk，W.，和R.Housley，“互联网X.509公钥基础设施证书和证书撤销列表（CRL）配置文件的算法和标识符”，RFC 3279，2002年4月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766]Orman，H.和P.Hoffman，“确定用于交换对称密钥的公钥的强度”，BCP 86，RFC 3766，2004年4月。
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[RFC3852]Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4556] Zhu, L. and B. Tung, "Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
[RFC4556]Zhu，L.和B.Tung，“Kerberos中初始身份验证的公钥加密（PKINIT）”，RFC 45562006年6月。
[RFC5280] 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", RFC 5280, May 2008.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 52802008年5月。
[X9.62] ANSI, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 2005.
[X9.62]ANSI，“金融服务业的公钥加密：椭圆曲线数字签名算法（ECDSA）”，ANSI X9.62，2005年。
[X9.63] ANSI, "Public Key Cryptography for the Financial Services Industry: Key Agreement and Key Transport using Elliptic Curve Cryptography", ANSI X9.63, 2001.
[X9.63]ANSI，“金融服务业的公钥加密：使用椭圆曲线加密的密钥协议和密钥传输”，ANSI X9.63，2001年。
[LENSTRA] Lenstra, A. and E. Verheul, "Selecting Cryptographic Key Sizes", Journal of Cryptography 14, 255-293, 2001.
[LENSTRA]LENSTRA，A.和E.Verheul，“选择加密密钥大小”，密码学杂志14255-2932001年。
[SEC2] Standards for Efficient Cryptography Group, "SEC 2 - Recommended Elliptic Curve Domain Parameters", Ver. 1.0, 2000, <http://www.secg.org>.
[SEC2]高效密码标准组，“SEC2-建议的椭圆曲线域参数”，第。1.0, 2000, <http://www.secg.org>.
Authors' Addresses
作者地址
Larry Zhu Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Larry Zhu微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: lzhu@microsoft.com
EMail: lzhu@microsoft.com
Karthik Jaganathan Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
Karthik Jaganathan微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: karthikj@microsoft.com
EMail: karthikj@microsoft.com
Kristin Lauter Microsoft Corporation One Microsoft Way Redmond, WA 98052 US
克里斯汀·劳特微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: klauter@microsoft.com
EMail: klauter@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
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 http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
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 ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.