Internet Engineering Task Force (IETF) S. Rose
Request for Comments: 6944 NIST
Updates: 2536, 2539, 3110, 4034, 4398, April 2013
5155, 5702, 5933
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Rose
Request for Comments: 6944 NIST
Updates: 2536, 2539, 3110, 4034, 4398, April 2013
5155, 5702, 5933
Category: Standards Track
ISSN: 2070-1721
Applicability Statement: DNS Security (DNSSEC) DNSKEY Algorithm Implementation Status
适用性声明：DNS安全（DNSSEC）DNSKEY算法实施状态
Abstract
摘要
The DNS Security Extensions (DNSSEC) requires the use of cryptographic algorithm suites for generating digital signatures over DNS data. There is currently an IANA registry for these algorithms, but there is no record of the recommended implementation status of each algorithm. This document provides an applicability statement on algorithm implementation status for DNSSEC component software. This document lists each algorithm's status based on the current reference. In the case that an algorithm is specified without an implementation status, this document assigns one. This document updates RFCs 2536, 2539, 3110, 4034, 4398, 5155, 5702, and 5933.
DNS安全扩展（DNSSEC）要求使用加密算法套件在DNS数据上生成数字签名。目前，这些算法有一个IANA注册中心，但没有每个算法的推荐实施状态记录。本文件提供了DNSSEC组件软件算法实现状态的适用性声明。本文档根据当前参考列出了每个算法的状态。如果指定的算法没有实现状态，本文档将指定一个。本文档更新了RFCs 2536、2539、3110、4034、4398、5155、5702和5933。
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/rfc6944.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6944.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. The DNS Security Algorithm Implementation Status Lists . . . . 3
2.1. Status Definitions . . . . . . . . . . . . . . . . . . . . 3
2.2. Algorithm Implementation Status Assignment Rationale . . . 4
2.3. DNSSEC Implementation Status Table . . . . . . . . . . . . 4
2.4. Specifying New Algorithms and Updating the Status of
Existing Entries . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3
2. The DNS Security Algorithm Implementation Status Lists . . . . 3
2.1. Status Definitions . . . . . . . . . . . . . . . . . . . . 3
2.2. Algorithm Implementation Status Assignment Rationale . . . 4
2.3. DNSSEC Implementation Status Table . . . . . . . . . . . . 4
2.4. Specifying New Algorithms and Updating the Status of
Existing Entries . . . . . . . . . . . . . . . . . . . . . 5
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . . 7
The Domain Name System (DNS) Security Extensions (DNSSEC) ([RFC4033], [RFC4034], [RFC4035], [RFC4509], [RFC5155], and [RFC5702]) uses digital signatures over DNS data to provide source authentication and integrity protection. DNSSEC uses an IANA registry to list codes for digital signature algorithms (consisting of a cryptographic algorithm and one-way hash function).
域名系统（DNS）安全扩展（DNSSEC）（[RFC4033]、[RFC4034]、[RFC4035]、[RFC4509]、[RFC5155]和[RFC5702]）使用DNS数据上的数字签名来提供源身份验证和完整性保护。DNSSEC使用IANA注册表列出数字签名算法的代码（由加密算法和单向哈希函数组成）。
The original list of algorithm status is found in [RFC4034]. Other DNSSEC RFCs have added new algorithms or changed the status of algorithms in the registry. However, implementers must read through all the documents in order to discover which algorithms are considered wise to implement, which are not, and which algorithms may become widely used in the future.
算法状态的原始列表见[RFC4034]。其他DNSSEC RFC添加了新算法或更改了算法在注册表中的状态。然而，实现者必须通读所有文档，以发现哪些算法被认为是明智的，哪些不是，以及哪些算法在未来可能会被广泛使用。
This document defines the current implementation status for all registered algorithms. If the status of algorithms changes, this document will be replaced with a new one establishing the new status; see Section 2.4.
本文档定义了所有注册算法的当前实现状态。如果算法状态发生变化，则本文件将替换为建立新状态的新文件；见第2.4节。
This document updates the following: [RFC2536], [RFC2539], [RFC3110], [RFC4034], [RFC4398], [RFC5155], [RFC5702], and [RFC5933].
本文档更新了以下内容：[RFC2536]、[RFC2539]、[RFC3110]、[RFC4034]、[RFC4398]、[RFC5155]、[RFC5702]和[RFC5933]。
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]中所述进行解释。
Must Implement: The algorithm MUST be implemented to interoperate with other implementations of this specification.
必须实现：必须实现该算法才能与本规范的其他实现进行互操作。
Must Not Implement: The algorithm MUST NOT be implemented. An algorithm with this status has known weaknesses.
不能实现：算法不能实现。具有这种状态的算法具有已知的弱点。
Recommended to Implement: The algorithm SHOULD be implemented. Utility and interoperability with other implementations will be improved when an algorithm with this status is implemented, though there might be occasions where it is reasonable not to implement the algorithm. An implementer must understand and weigh the full implications of choosing not to implement this particular algorithm.
建议实施：应实施算法。当实现具有这种状态的算法时，实用性和与其他实现的互操作性将得到改善，尽管在某些情况下不实现该算法是合理的。实现者必须理解并权衡选择不实现此特定算法的全部含义。
Optional: The algorithm MAY be implemented, but all implementations MUST be prepared to interoperate with implementations that do or do not implement this algorithm.
可选：可以实现该算法，但所有实现都必须准备好与实现或不实现该算法的实现进行互操作。
RSASHA1 has an implementation status of Must Implement, consistent with [RFC4034]. RSAMD5 has an implementation status of Must Not Implement because of known weaknesses in MD5.
RSASHA1的实施状态为必须实施，与[RFC4034]一致。由于MD5中的已知弱点，RSAMD5的实施状态为“不得实施”。
The status of RSASHA1-NSEC3-SHA1 is set to Recommended to Implement as many deployments use NSEC3. The status of RSA/SHA-256 and RSA/ SHA-512 are also set to Recommended to Implement as major deployments (such as the root zone) use these algorithms [ROOTDPS]. It is believed that RSA/SHA-256 or RSA/SHA-512 algorithms will replace older algorithms (e.g., RSA/SHA-1) that have a perceived weakness.
RSASHA1-NSEC3-SHA1的状态设置为“建议”以实施使用NSEC3的部署。RSA/SHA-256和RSA/SHA-512的状态也被设置为建议实施，因为主要部署（如根区域）使用这些算法[ROOTDPS]。据信，RSA/SHA-256或RSA/SHA-512算法将取代具有明显弱点的旧算法（如RSA/SHA-1）。
Likewise, ECDSA with the two identified curves (ECDSAP256SHA256 and ECDSAP384SHA384) is an algorithm that may see widespread use due to the perceived similar level of security offered with smaller key size compared to the key sizes of algorithms such as RSA. Therefore, ECDSAP256SHA256 and ECDSAP384SHA384 are Recommended to Implement.
同样，具有两条已识别曲线（ECDSAP256SHA256和ECDSAP384SHA384）的ECDSA是一种可能会得到广泛使用的算法，因为与RSA等算法的密钥大小相比，较小的密钥大小可以提供相似的安全级别。因此，建议实施ECDSAP256SHA256和ECDSAP384SHA384。
All other algorithms used in DNSSEC specified without an implementation status are currently set to Optional.
DNSSEC中使用的所有其他算法（未指定实现状态）当前都设置为可选。
The DNSSEC algorithm implementation status table is listed below. Only the algorithms already specified for use with DNSSEC at the time of writing are listed.
DNSSEC算法实施状态表如下所示。仅列出编写本文时已指定用于DNSSEC的算法。
+------------+------------+-------------------+-------------------+
| Must | Must Not | Recommended | Optional |
| Implement | Implement | to Implement | |
+------------+------------+-------------------+-------------------+
| | | | |
| RSASHA1 | RSAMD5 | RSASHA256 | Any |
| | | RSASHA1-NSEC3 | registered |
| | | -SHA1 | algorithm |
| | | RSASHA512 | not listed in |
| | | ECDSAP256SHA256 | this table |
| | | ECDSAP384SHA384 | |
+------------+------------+-------------------+-------------------+
+------------+------------+-------------------+-------------------+
| Must | Must Not | Recommended | Optional |
| Implement | Implement | to Implement | |
+------------+------------+-------------------+-------------------+
| | | | |
| RSASHA1 | RSAMD5 | RSASHA256 | Any |
| | | RSASHA1-NSEC3 | registered |
| | | -SHA1 | algorithm |
| | | RSASHA512 | not listed in |
| | | ECDSAP256SHA256 | this table |
| | | ECDSAP384SHA384 | |
+------------+------------+-------------------+-------------------+
This table does not list the Reserved values in the IANA registry table or the values for INDIRECT (252), PRIVATE (253), and PRIVATEOID (254). These values may relate to more than one algorithm and are therefore up to the implementer's discretion. As noted, any algorithm not listed in the table is Optional. As of this writing, the Optional algorithms are DSASHA1, DH, DSA-NSEC3-SHA1, and GOST-ECC, but in general, anything not explicitly listed is Optional.
此表未列出IANA注册表表中的保留值或间接（252）、私有（253）和私有OID（254）的值。这些值可能涉及多个算法，因此由实现者自行决定。如前所述，表中未列出的任何算法都是可选的。在撰写本文时，可选算法为DSASHA1、DH、DSA-NSEC3-SHA1和GOST-ECC，但一般来说，未明确列出的任何算法都是可选的。
2.4. Specifying New Algorithms and Updating the Status of Existing Entries
2.4. 指定新算法并更新现有条目的状态
[RFC6014] establishes a parallel procedure for adding a registry entry for a new algorithm other than a standards track document. Because any algorithm not listed in the foregoing table is Optional, algorithms entered into the registry using the [RFC6014] procedure are automatically Optional.
[RFC6014]建立了一个并行过程，用于为标准跟踪文档以外的新算法添加注册表项。由于上表中未列出的任何算法都是可选的，因此使用[RFC6014]过程输入注册表的算法将自动可选。
It has turned out to be useful for implementations to refer to a single document that specifies the implementation status of every algorithm. Accordingly, when a new algorithm is to be registered with a status other than Optional, this document shall be made obsolete by a new document that adds the new algorithm to the table in Section 2.3. Similarly, if the status of any algorithm in the table in Section 2.3 changes, a new document shall make this document obsolete; that document shall include a replacement of the table in Section 2.3. This way, the goal of having one authoritative document to specify all the status values is achieved.
事实证明，对于实现来说，引用指定每个算法的实现状态的单个文档是非常有用的。因此，当以非可选状态注册新算法时，应通过将新算法添加到第2.3节表格中的新文件将本文件作废。同样，如果第2.3节表格中任何算法的状态发生变化，新文件应使该文件作废；该文件应包括第2.3节中表格的替换。这样，就实现了使用一个权威文档来指定所有状态值的目标。
This document cannot be updated, only made obsolete and replaced by a successor document.
此文档无法更新，只能作废并由后续文档替换。
This document lists the implementation status of cryptographic algorithms used with DNSSEC. These algorithms are maintained in an IANA registry at http://www.iana.org/assignments/dns-sec-alg-numbers. Because this document establishes the implementation status of every algorithm, it has been listed as a reference for the registry itself.
本文档列出了与DNSSEC一起使用的加密算法的实施状态。这些算法保存在http://www.iana.org/assignments/dns-sec-alg-numbers. 由于本文档确定了每个算法的实现状态，因此已将其列为注册表本身的参考。
This document lists, and in some cases assigns, the implementation status of cryptographic algorithms used with DNSSEC. It is not meant to be a discussion on algorithm superiority. No new security considerations are raised in this document, though prior description of algorithms as NOT RECOMMENDED (see [RFC4034]) has been recast as Must Not Implement.
本文档列出并在某些情况下指定了DNSSEC使用的加密算法的实施状态。这并不是要讨论算法的优越性。本文件中未提出新的安全注意事项，尽管先前对不推荐的算法的描述（参见[RFC4034]）已被改写为不得实施。
[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月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536]Eastlake，D.，“域名系统（DNS）中的DSA密钥和SIG”，RFC 25361999年3月。
[RFC2539] Eastlake, D., "Storage of Diffie-Hellman Keys in the Domain Name System (DNS)", RFC 2539, March 1999.
[RFC2539]伊斯特莱克，D.，“域名系统（DNS）中Diffie-Hellman密钥的存储”，RFC 25391999年3月。
[RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3110]Eastlake，D.，“域名系统（DNS）中的RSA/SHA-1 SIGs和RSA密钥”，RFC 3110，2001年5月。
[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月。
[RFC4398] Josefsson, S., "Storing Certificates in the Domain Name System (DNS)", RFC 4398, March 2006.
[RFC4398]Josefsson，S.，“在域名系统（DNS）中存储证书”，RFC 4398，2006年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月。
[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月。
[RFC5702] Jansen, J., "Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5702, October 2009.
[RFC5702]Jansen，J.，“在DNSSEC的DNSKEY和RRSIG资源记录中使用带有RSA的SHA-2算法”，RFC 5702，2009年10月。
[RFC5933] Dolmatov, V., Chuprina, A., and I. Ustinov, "Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC", RFC 5933, July 2010.
[RFC5933]Dolmatov，V.，Chuprina，A.，和I.Ustinov，“在DNSSEC的DNSKEY和RRSIG资源记录中使用GOST签名算法”，RFC 59332010年7月。
[RFC6014] Hoffman, P., "Cryptographic Algorithm Identifier Allocation for DNSSEC", RFC 6014, November 2010.
[RFC6014]Hoffman，P.，“DNSSEC的密码算法标识符分配”，RFC6014010年11月。
[ROOTDPS] Ljunggren, F., Okubo, T., Lamb, R., and J. Schlyter, "DNSSEC Practice Statement for the Root Zone KSK Operator", DNS ROOTDPS, May 2010, <http://www.root-dnssec.org/wp-content/uploads/2010/06/ icann-dps-00.txt>.
[ROOTDPS]Ljunggren，F.，Okubo，T.，Lamb，R.，和J.Schlyter，“根区域KSK运营商的DNSSEC实践声明”，DNS ROOTDPS，2010年5月<http://www.root-dnssec.org/wp-content/uploads/2010/06/ icann-dps-00.txt>。
Author's Address
作者地址
Scott Rose NIST 100 Bureau Dr. Gaithersburg, MD 20899 USA
斯科特·罗斯NIST 100局盖瑟斯堡博士，美国马里兰州20899
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com
Phone: +1-301-975-8439
EMail: scottr.nist@gmail.com