Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6605 VPN Consortium
Category: Standards Track W.C.A. Wijngaards
ISSN: 2070-1721 NLnet Labs
April 2012
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 6605 VPN Consortium
Category: Standards Track W.C.A. Wijngaards
ISSN: 2070-1721 NLnet Labs
April 2012
Elliptic Curve Digital Signature Algorithm (DSA) for DNSSEC
DNSSEC的椭圆曲线数字签名算法（DSA）
Abstract
摘要
This document describes how to specify Elliptic Curve Digital Signature Algorithm (DSA) keys and signatures in DNS Security (DNSSEC). It lists curves of different sizes and uses the SHA-2 family of hashes for signatures.
本文档描述如何在DNS安全性（DNSSEC）中指定椭圆曲线数字签名算法（DSA）密钥和签名。它列出了不同大小的曲线，并使用SHA-2哈希族进行签名。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6605.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6605.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
DNSSEC, which is broadly defined in RFCs 4033, 4034, and 4035 ([RFC4033], [RFC4034], and [RFC4035]), uses cryptographic keys and digital signatures to provide authentication of DNS data. Currently, the most popular signature algorithm is RSA with SHA-1, using keys that are 1024 or 2048 bits long.
DNSSEC在RFCs 4033、4034和4035（[RFC4033]、[RFC4034]和[RFC4035]）中有广泛的定义，它使用加密密钥和数字签名来提供DNS数据的身份验证。目前，最流行的签名算法是带有SHA-1的RSA，使用1024或2048位长的密钥。
This document defines the DNSKEY and RRSIG resource records (RRs) of two new signing algorithms: ECDSA (Elliptic Curve DSA) with curve P-256 and SHA-256, and ECDSA with curve P-384 and SHA-384. (A description of ECDSA can be found in [FIPS-186-3].) This document also defines the DS RR for the SHA-384 one-way hash algorithm; the associated DS RR for SHA-256 is already defined in RFC 4509 [RFC4509]. [RFC6090] provides a good introduction to implementing ECDSA.
本文档定义了两种新签名算法的DNSKEY和RRSIG资源记录（RRs）：带有曲线P-256和SHA-256的ECDSA（椭圆曲线DSA），以及带有曲线P-384和SHA-384的ECDSA。（ECDSA的说明见[FIPS-186-3]）本文件还定义了SHA-384单向散列算法的DS RR；SHA-256的相关DS RR已在RFC 4509[RFC4509]中定义。[RFC6090]很好地介绍了如何实现ECDSA。
Current estimates are that ECDSA with curve P-256 has an approximate equivalent strength to RSA with 3072-bit keys. Using ECDSA with curve P-256 in DNSSEC has some advantages and disadvantages relative to using RSA with SHA-256 and with 3072-bit keys. ECDSA keys are much shorter than RSA keys; at this size, the difference is 256 versus 3072 bits. Similarly, ECDSA signatures are much shorter than RSA signatures. This is relevant because DNSSEC stores and transmits both keys and signatures.
目前的估计是，具有曲线P-256的ECDSA与具有3072位密钥的RSA具有近似等效的强度。在DNSSEC中使用带有曲线P-256的ECDSA与使用带有SHA-256和3072位密钥的RSA相比，有一些优点和缺点。ECDSA密钥比RSA密钥短得多；在此大小下，差值为256位与3072位。类似地，ECDSA签名比RSA签名短得多。这是相关的，因为DNSSEC存储并传输密钥和签名。
In the two signing algorithms defined in this document, the size of the key for the elliptic curve is matched with the size of the output of the hash algorithm. This design is based on the widespread belief that the equivalent strength of P-256 and P-384 is half the length of the key, and also that the equivalent strength of SHA-256 and SHA-384 is half the length of the key. Using matched strengths prevents an attacker from choosing the weaker half of a signature algorithm. For example, in a signature that uses RSA with 2048-bit keys and SHA-256, the signing portion is significantly weaker than the hash portion, whereas the two algorithms here are balanced.
在本文定义的两种签名算法中，椭圆曲线密钥的大小与哈希算法输出的大小相匹配。该设计基于一个普遍的信念，即P-256和P-384的等效强度是钥匙长度的一半，并且SHA-256和SHA-384的等效强度是钥匙长度的一半。使用匹配的强度可以防止攻击者选择签名算法中较弱的那一半。例如，在使用带有2048位密钥和SHA-256的RSA的签名中，签名部分明显弱于散列部分，而这里的两种算法是平衡的。
Signing with ECDSA is significantly faster than with RSA (over 20 times in some implementations). However, validating RSA signatures is significantly faster than validating ECDSA signatures (about 5 times faster in some implementations).
使用ECDSA进行签名的速度比使用RSA快得多（在某些实现中超过20倍）。但是，验证RSA签名要比验证ECDSA签名快得多（在某些实现中大约快5倍）。
Some of the material in this document is copied liberally from RFC 6460 [RFC6460].
本文件中的一些材料是从RFC 6460[RFC6460]自由复制的。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
SHA-384 is defined in FIPS 180-3 [FIPS-180-3] and RFC 6234 [RFC6234], and is similar to SHA-256 in many ways. The implementation of SHA-384 in DNSSEC follows the implementation of SHA-256 as specified in RFC 4509 except that the underlying algorithm is SHA-384, the digest value is 48 bytes long, and the digest type code is 4.
SHA-384在FIPS 180-3[FIPS-180-3]和RFC 6234[RFC6234]中有定义，在许多方面与SHA-256类似。DNSSEC中SHA-384的实现遵循RFC 4509中指定的SHA-256的实现，但底层算法为SHA-384，摘要值为48字节长，摘要类型代码为4。
Verifying ECDSA signatures requires agreement between the signer and the verifier of the parameters used. FIPS 186-3 [FIPS-186-3] lists some NIST-recommended elliptic curves. (Other documents give more detail on ECDSA than is given in FIPS 186-3.) These are the same curves listed in RFC 5114 [RFC5114]. The curves used in this document are:
验证ECDSA签名需要签名者和验证者就使用的参数达成一致。FIPS 186-3[FIPS-186-3]列出了一些NIST推荐的椭圆曲线。（与FIPS 186-3相比，其他文件给出了更多关于ECDSA的详细信息。）这些曲线与RFC 5114[RFC5114]中列出的曲线相同。本文件中使用的曲线为：
FIPS 186-3 RFC 5114
------------------------------------------------------------------
P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6)
P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7)
FIPS 186-3 RFC 5114
------------------------------------------------------------------
P-256 (Section D.1.2.3) 256-bit Random ECP Group (Section 2.6)
P-384 (Section D.1.2.4) 384-bit Random ECP Group (Section 2.7)
ECDSA public keys consist of a single value, called "Q" in FIPS 186-3. In DNSSEC keys, Q is a simple bit string that represents the uncompressed form of a curve point, "x | y".
ECDSA公钥由一个值组成，在FIPS 186-3中称为“Q”。在DNSSEC键中，Q是一个简单的位字符串，表示曲线点“x | y”的未压缩形式。
The ECDSA signature is the combination of two non-negative integers, called "r" and "s" in FIPS 186-3. The two integers, each of which is formatted as a simple octet string, are combined into a single longer octet string for DNSSEC as the concatenation "r | s". (Conversion of the integers to bit strings is described in Section C.2 of FIPS 186-3.) For P-256, each integer MUST be encoded as 32 octets; for P-384, each integer MUST be encoded as 48 octets.
ECDSA签名是两个非负整数的组合，在FIPS 186-3中称为“r”和“s”。对于DNSSEC，两个整数（每个整数的格式为简单的八位字节字符串）组合为一个较长的八位字节字符串，作为串联“r | s”。（FIPS 186-3第C.2节描述了整数到位字符串的转换。）对于P-256，每个整数必须编码为32个八位字节；对于P-384，每个整数必须编码为48个八位字节。
The algorithm numbers associated with the DNSKEY and RRSIG resource records are fully defined in the IANA Considerations section. They are:
与DNSKEY和RRSIG资源记录相关的算法编号在IANA注意事项部分中有完整定义。他们是：
o DNSKEY and RRSIG RRs signifying ECDSA with the P-256 curve and SHA-256 use the algorithm number 13.
o DNSKEY和RRSIG RRs使用P-256曲线表示ECDSA，SHA-256使用13号算法。
o DNSKEY and RRSIG RRs signifying ECDSA with the P-384 curve and SHA-384 use the algorithm number 14.
o DNSKEY和RRSIG RRs使用P-384曲线表示ECDSA，SHA-384使用14号算法。
Conformant implementations that create records to be put into the DNS MUST implement signing and verification for both of the above algorithms. Conformant DNSSEC verifiers MUST implement verification for both of the above algorithms.
创建要放入DNS的记录的一致性实现必须为上述两种算法实现签名和验证。一致性DNSSEC验证器必须对上述两种算法进行验证。
RFC 5155 [RFC5155] defines new algorithm identifiers for existing signing algorithms to indicate that zones signed with these algorithm identifiers can use NSEC3 as well as NSEC records to provide denial of existence. That mechanism was chosen to protect implementations predating RFC 5155 from encountering resource records they could not know about. This document does not define such algorithm aliases.
RFC 5155[RFC5155]为现有签名算法定义了新的算法标识符，以指示使用这些算法标识符签名的区域可以使用NSEC3以及NSEC记录来拒绝存在。选择该机制是为了保护RFC 5155之前的实现不会遇到他们不知道的资源记录。本文档未定义此类算法别名。
A DNSSEC validator that implements the signing algorithms defined in this document MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in RFC 5155. An authoritative server that does not implement NSEC3 MAY still serve zones that use the signing algorithms defined in this document with NSEC denial of existence.
实现本文档中定义的签名算法的DNSSEC验证器必须能够使用RFC 5155中定义的哈希算法1验证NSEC和NSEC3形式的否定答案。未实现NSEC3的权威服务器可能仍然为使用本文档中定义的签名算法的区域提供NSEC拒绝存在服务。
The following are some examples of ECDSA keys and signatures in DNS format.
以下是DNS格式的ECDSA密钥和签名的一些示例。
Private-key-format: v1.2
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ=
Private-key-format: v1.2
Algorithm: 13 (ECDSAP256SHA256)
PrivateKey: GU6SnQ/Ou+xC5RumuIUIuJZteXT2z0O/ok1s38Et6mQ=
example.net. 3600 IN DNSKEY 257 3 13 (
GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )
example.net. 3600 IN DNSKEY 257 3 13 (
GojIhhXUN/u4v54ZQqGSnyhWJwaubCvTmeexv7bR6edb
krSqQpF64cYbcB7wNcP+e+MAnLr+Wi9xMWyQLc8NAA== )
example.net. 3600 IN DS 55648 13 2 ( b4c8c1fe2e7477127b27115656ad6256f424625bf5c1 e2770ce6d6e37df61d17 )
例如.net。DS 55648 13 2中的3600（B4C8C1FE2E7477127B27115656AD6256F42462BF5C1 e2770ce6d6e37df61d17）
www.example.net. 3600 IN A 192.0.2.1 www.example.net. 3600 IN RRSIG A 13 3 3600 ( 20100909100439 20100812100439 55648 example.net. qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw== )
www.example.net。在192.0.2.1 www.example.net中使用3600。RRSIG A 13 3 3600中的3600（20100909100439 20100812100439 55648 example.net.qx6wLYqmh+l9oCKTN6qIc+bw6ya+KJ8oMz0YP107epXA yGmt+3SNruPFKG7tZoLBLlUzGGus7ZwmwWep666VCw==）
Private-key-format: v1.2 Algorithm: 14 (ECDSAP384SHA384) PrivateKey: WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw W7BOrbawVmVe0d9V94SR
私钥格式：v1.2算法：14（ECDSAP384SHA384）私钥：WURgWHCcYIYUPWgeLmiPY2DJJk02vgrmTfitxgqcL4vw W7BOrbawVmVe0d9V94SR
example.net. 3600 IN DNSKEY 257 3 14 (
xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1
w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8
/uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 )
example.net. 3600 IN DNSKEY 257 3 14 (
xKYaNhWdGOfJ+nPrL8/arkwf2EY3MDJ+SErKivBVSum1
w/egsXvSADtNJhyem5RCOpgQ6K8X1DRSEkrbYQ+OB+v8
/uX45NBwY8rp65F6Glur8I/mlVNgF6W/qTI37m40 )
example.net. 3600 IN DS 10771 14 4 ( 72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 6df983d6 )
例如.net。DS 10771 14 4中的3600（72d7b62976ce06438e9c0bf319013cf801f09ecc84b8 d7e9495f27e305c6a9b0563a9b5f4d288405c3008a94 6df983d6）
www.example.net. 3600 IN A 192.0.2.1 www.example.net. 3600 IN RRSIG A 14 3 3600 ( 20100909102025 20100812102025 10771 example.net. /L5hDKIvGDyI1fcARX3z65qrmPsVz73QD1Mr5CEqOiLP 95hxQouuroGCeZOvzFaxsT8Glr74hbavRKayJNuydCuz WTSSPdz7wnqXL5bdcJzusdnI0RSMROxxwGipWcJm )
www.example.net。在192.0.2.1 www.example.net中使用3600。RRSIG A 14 3 3600中的3600（20100909102025 20100812102025 10771 example.net./l5hdkivgdyi1farx3z65qrmpsvz73qd1mr5ceqoilp 95hxquuuuuuuuuozvzfaxst8glr74hbavrkayjnuydcuz wtsspDz7wnqxl5bdcjzusdni0rsmroxwgipwcjm）
This document updates the IANA registry for digest types in DS records, currently called "Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms". The following entry has been added:
本文档更新了IANA注册表中DS记录中的摘要类型，当前称为“委托签名者（DS）资源记录（RR）类型摘要算法”。已添加以下条目：
Value 4 Digest Type SHA-384 Status OPTIONAL
值4摘要类型SHA-384状态可选
This document updates the IANA registry "Domain Name System Security (DNSSEC) Algorithm Numbers". The following two entries have been added to the registry:
本文档更新IANA注册表“域名系统安全（DNSSEC）算法编号”。以下两项已添加到注册表中：
Number 13 Description ECDSA Curve P-256 with SHA-256 Mnemonic ECDSAP256SHA256 Zone Signing Y Trans. Sec. * Reference This document
编号13描述ECDSA曲线P-256，带SHA-256助记符ECDSAP256SHA256区域签名Y Trans。第*节参考本文件
Number 14 Description ECDSA Curve P-384 with SHA-384 Mnemonic ECDSAP384SHA384 Zone Signing Y Trans. Sec. * Reference This document
编号14描述ECDSA曲线P-384，带SHA-384助记符ECDSAP384SHA384区域符号Y Trans。第*节参考本文件
* There has been no determination of standardization of the use of this algorithm with Transaction Security.
* 目前还没有确定该算法与事务安全性的标准化使用。
The cryptographic work factor of ECDSA with curve P-256 or P-384 is generally considered to be equivalent to half the size of the key, or 128 bits and 192 bits, respectively. Such an assessment could, of course, change in the future if new attacks that work better than the ones known today are found.
曲线为P-256或P-384的ECDSA的加密工作系数通常被认为等于密钥大小的一半，或分别为128位和192位。当然，如果发现比目前已知的攻击更有效的新攻击，这种评估在未来可能会改变。
The security considerations listed in RFC 4509 apply here as well.
RFC 4509中列出的安全注意事项也适用于此处。
[FIPS-180-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Secure Hash Standard (SHS)", FIPS 180-3, October 2008.
[FIPS-180-3]美国商务部国家标准与技术研究所，“安全哈希标准（SHS）”，FIPS 180-3，2008年10月。
[FIPS-186-3] National Institute of Standards and Technology, U.S. Department of Commerce, "Digital Signature Standard", FIPS 186-3, June 2009.
[FIPS-186-3]美国商务部国家标准与技术研究所，“数字签名标准”，FIPS 186-3，2009年6月。
[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月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的资源记录”，RFC 40342005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[RFC4509] Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)", RFC 4509, May 2006.
[RFC4509]Hardaker，W.“SHA-256在DNSSEC委托签署人（DS）资源记录（RRs）中的使用”，RFC 4509，2006年5月。
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman Groups for Use with IETF Standards", RFC 5114, January 2008.
[RFC5114]Lepinski，M.和S.Kent，“与IETF标准一起使用的其他Diffie-Hellman组”，RFC 5114，2008年1月。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]Laurie，B.，Sisson，G.，Arends，R.，和D.Blacka，“DNS安全（DNSSEC）哈希认证拒绝存在”，RFC 51552008年3月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090]McGrew，D.，Igoe，K.，和M.Salter，“基本椭圆曲线密码算法”，RFC 60902011年2月。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6234]Eastlake 3rd，D.和T.Hansen，“美国安全哈希算法（基于SHA和SHA的HMAC和HKDF）”，RFC 6234，2011年5月。
[RFC6460] Salter, M. and R. Housley, "Suite B Profile for Transport Layer Security (TLS)", RFC 6460, January 2012.
[RFC6460]Salter，M.和R.Housley，“传输层安全（TLS）的套件B配置文件”，RFC 64602012年1月。
Authors' Addresses
作者地址
Paul Hoffman VPN Consortium
保罗·霍夫曼VPN联盟
EMail: paul.hoffman@vpnc.org
EMail: paul.hoffman@vpnc.org
Wouter C.A. Wijngaards NLnet Labs
沃特C.A.维恩加德斯NLnet实验室
EMail: wouter@nlnetlabs.nl
EMail: wouter@nlnetlabs.nl