Network Working Group J. Jansen
Request for Comments: 5702 NLnet Labs
Category: Standards Track October 2009
Network Working Group J. Jansen
Request for Comments: 5702 NLnet Labs
Category: Standards Track October 2009
Use of SHA-2 Algorithms with RSA in DNSKEY and RRSIG Resource Records for DNSSEC
在DNSSEC的DNSKEY和RRSIG资源记录中使用带RSA的SHA-2算法
Abstract
摘要
This document describes how to produce RSA/SHA-256 and RSA/SHA-512 DNSKEY and RRSIG resource records for use in the Domain Name System Security Extensions (RFC 4033, RFC 4034, and RFC 4035).
本文档介绍如何生成RSA/SHA-256和RSA/SHA-512 DNSKEY和RRSIG资源记录，以用于域名系统安全扩展（RFC 4033、RFC 4034和RFC 4035）。
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 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 BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括《信托法律条款》第4.e节中所述的简化BSD许可文本，并且提供BSD许可中所述的代码组件时不提供任何担保。
Table of Contents
目录
1. Introduction ....................................................2
2. DNSKEY Resource Records .........................................3
2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
3. RRSIG Resource Records ..........................................3
3.1. RSA/SHA-256 RRSIG Resource Records .........................4
3.2. RSA/SHA-512 RRSIG Resource Records .........................4
4. Deployment Considerations .......................................5
4.1. Key Sizes ..................................................5
4.2. Signature Sizes ............................................5
5. Implementation Considerations ...................................5
5.1. Support for SHA-2 Signatures ...............................5
5.2. Support for NSEC3 Denial of Existence ......................5
6. Examples ........................................................6
6.1. RSA/SHA-256 Key and Signature ..............................6
6.2. RSA/SHA-512 Key and Signature ..............................7
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
8.1. SHA-1 versus SHA-2 Considerations for RRSIG
Resource Records ...........................................8
8.2. Signature Type Downgrade Attacks ...........................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction ....................................................2
2. DNSKEY Resource Records .........................................3
2.1. RSA/SHA-256 DNSKEY Resource Records ........................3
2.2. RSA/SHA-512 DNSKEY Resource Records ........................3
3. RRSIG Resource Records ..........................................3
3.1. RSA/SHA-256 RRSIG Resource Records .........................4
3.2. RSA/SHA-512 RRSIG Resource Records .........................4
4. Deployment Considerations .......................................5
4.1. Key Sizes ..................................................5
4.2. Signature Sizes ............................................5
5. Implementation Considerations ...................................5
5.1. Support for SHA-2 Signatures ...............................5
5.2. Support for NSEC3 Denial of Existence ......................5
6. Examples ........................................................6
6.1. RSA/SHA-256 Key and Signature ..............................6
6.2. RSA/SHA-512 Key and Signature ..............................7
7. IANA Considerations .............................................8
8. Security Considerations .........................................8
8.1. SHA-1 versus SHA-2 Considerations for RRSIG
Resource Records ...........................................8
8.2. Signature Type Downgrade Attacks ...........................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
The Domain Name System (DNS) is the global, hierarchical distributed database for Internet Naming. The DNS has been extended to use cryptographic keys and digital signatures for the verification of the authenticity and integrity of its data. [RFC4033], [RFC4034], and [RFC4035] describe these DNS Security Extensions, called DNSSEC.
域名系统（DNS）是用于Internet命名的全局、分层分布式数据库。DNS已扩展到使用加密密钥和数字签名来验证其数据的真实性和完整性。[RFC4033]、[RFC4034]和[RFC4035]描述了这些DNS安全扩展，称为DNSSEC。
RFC 4034 describes how to store DNSKEY and RRSIG resource records, and specifies a list of cryptographic algorithms to use. This document extends that list with the algorithms RSA/SHA-256 and RSA/ SHA-512, and specifies how to store DNSKEY data and how to produce RRSIG resource records with these hash algorithms.
RFC 4034描述了如何存储DNSKEY和RRSIG资源记录，并指定了要使用的加密算法列表。本文档使用RSA/SHA-256和RSA/SHA-512算法扩展了该列表，并指定了如何存储DNSKEY数据以及如何使用这些哈希算法生成RRSIG资源记录。
Familiarity with DNSSEC, RSA, and the SHA-2 [FIPS.180-3.2008] family of algorithms is assumed in this document.
本文档假设您熟悉DNSSEC、RSA和SHA-2[FIPS.180-3.2008]算法系列。
To refer to both SHA-256 and SHA-512, this document will use the name SHA-2. This is done to improve readability. When a part of text is specific for either SHA-256 or SHA-512, their specific names are used. The same goes for RSA/SHA-256 and RSA/SHA-512, which will be grouped using the name RSA/SHA-2.
为了同时参考SHA-256和SHA-512，本文件将使用名称SHA-2。这样做是为了提高可读性。当文本的一部分特定于SHA-256或SHA-512时，将使用它们的特定名称。RSA/SHA-256和RSA/SHA-512也是如此，它们将使用名称RSA/SHA-2进行分组。
The term "SHA-2" is not officially defined but is usually used to refer to the collection of the algorithms SHA-224, SHA-256, SHA-384, and SHA-512. Since SHA-224 and SHA-384 are not used in DNSSEC, SHA-2 will only refer to SHA-256 and SHA-512 in this document.
术语“SHA-2”没有正式定义，但通常用于指算法SHA-224、SHA-256、SHA-384和SHA-512的集合。由于DNSSEC中未使用SHA-224和SHA-384，因此本文件中SHA-2仅参考SHA-256和SHA-512。
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]中所述进行解释。
The format of the DNSKEY RR can be found in [RFC4034]. [RFC3110] describes the use of RSA/SHA-1 for DNSSEC signatures.
DNSKEY RR的格式可在[RFC4034]中找到。[RFC3110]介绍了RSA/SHA-1对DNSSEC签名的使用。
RSA public keys for use with RSA/SHA-256 are stored in DNSKEY resource records (RRs) with the algorithm number 8.
用于RSA/SHA-256的RSA公钥存储在DNSKEY资源记录（RRs）中，算法编号为8。
For interoperability, as in [RFC3110], the key size of RSA/SHA-256 keys MUST NOT be less than 512 bits and MUST NOT be more than 4096 bits.
对于互操作性，如[RFC3110]中所述，RSA/SHA-256密钥的密钥大小不得小于512位，且不得大于4096位。
RSA public keys for use with RSA/SHA-512 are stored in DNSKEY resource records (RRs) with the algorithm number 10.
用于RSA/SHA-512的RSA公钥存储在DNSKEY资源记录（RRs）中，算法编号为10。
The key size of RSA/SHA-512 keys MUST NOT be less than 1024 bits and MUST NOT be more than 4096 bits.
RSA/SHA-512密钥的密钥大小不得小于1024位，且不得超过4096位。
The value of the signature field in the RRSIG RR follows the RSASSA-PKCS1-v1_5 signature scheme and is calculated as follows. The values for the RDATA fields that precede the signature data are specified in [RFC4034].
RRSIG RR中签名字段的值遵循RSASSA-PKCS1-v1_5签名方案，计算如下。[RFC4034]中指定了签名数据之前的RDATA字段的值。
hash = SHA-XXX(data)
散列=SHA-XXX（数据）
Here XXX is either 256 or 512, depending on the algorithm used, as specified in FIPS PUB 180-3; "data" is the wire format data of the resource record set that is signed, as specified in [RFC4034].
此处XXX为256或512，具体取决于所使用的算法，如FIPS PUB 180-3所述；“数据”是已签名的资源记录集的有线格式数据，如[RFC4034]中所述。
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
Here "|" is concatenation; "00", "01", "FF", and "00" are fixed octets of corresponding hexadecimal value; "e" is the private exponent of the signing RSA key; and "n" is the public modulus of the signing key. The FF octet MUST be repeated the exact number of times so that the total length of the concatenated term in parentheses equals the length of the modulus of the signer's public key ("n").
这里的“|”是串联；“00”、“01”、“FF”和“00”是对应十六进制值的固定八位字节；“e”是签名RSA密钥的私有指数；“n”是签名密钥的公共模。FF八位字节必须重复精确的次数，以便括号中的连接项的总长度等于签名者公钥的模的长度（“n”）。
The "prefix" is intended to make the use of standard cryptographic libraries easier. These specifications are taken directly from the specifications of RSASSA-PKCS1-v1_5 in PKCS #1 v2.1 (Section 8.2 of [RFC3447]), and EMSA-PKCS1-v1_5 encoding in PKCS #1 v2.1 (Section 9.2 of [RFC3447]). The prefixes for the different algorithms are specified below.
“前缀”旨在简化标准加密库的使用。这些规范直接取自PKCS#1 v2.1（RFC3447）第8.2节）中的RSASSA-PKCS1-v1_5规范和PKCS#1 v2.1（RFC3447）第9.2节）中的EMSA-PKCS1-v1_5编码规范。下面指定了不同算法的前缀。
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8.
RSA/SHA-256签名使用算法编号为8的RRSIG资源记录（RRs）存储在DNS中。
The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as specified in PKCS #1 v2.1 [RFC3447]:
前缀是ASN.1 DER SHA-256算法指示符前缀，如PKCS#1 v2.1[RFC3447]中所述：
hex 30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
六角30 31 30 0d 06 09 60 86 48 01 65 03 04 02 01 05 00 04 20
RSA/SHA-512 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 10.
RSA/SHA-512签名使用算法编号为10的RRSIG资源记录（RRs）存储在DNS中。
The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as specified in PKCS #1 v2.1 [RFC3447]:
前缀是ASN.1 DER SHA-512算法指示符前缀，如PKCS#1 v2.1[RFC3447]中所述：
hex 30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
六角30 51 30 0d 06 09 60 86 48 01 65 03 04 02 03 05 00 04 40
Apart from the restrictions in Section 2, this document will not specify what size of keys to use. That is an operational issue and depends largely on the environment and intended use. A good starting point for more information would be NIST SP 800-57 [NIST800-57].
除第2节中的限制外，本文件不会指定要使用的钥匙的大小。这是一个操作问题，主要取决于环境和预期用途。NIST SP 800-57[NIST 800-57]是获取更多信息的良好起点。
In this family of signing algorithms, the size of signatures is related to the size of the key and not to the hashing algorithm used in the signing process. Therefore, RRSIG resource records produced with RSA/SHA-256 or RSA/SHA-512 will have the same size as those produced with RSA/SHA-1, if the keys have the same length.
在这一系列签名算法中，签名的大小与密钥的大小有关，而与签名过程中使用的哈希算法无关。因此，如果密钥具有相同的长度，则使用RSA/SHA-256或RSA/SHA-512生成的RRSIG资源记录的大小将与使用RSA/SHA-1生成的资源记录的大小相同。
DNSSEC-aware implementations SHOULD be able to support RRSIG and DNSKEY resource records created with the RSA/SHA-2 algorithms as defined in this document.
支持DNSSEC的实现应该能够支持使用本文档中定义的RSA/SHA-2算法创建的RRSIG和DNSKEY资源记录。
[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 about which they could not know. This document does not define such algorithm aliases.
[RFC5155]为现有签名算法定义了新的算法标识符，以指示使用这些算法标识符签名的区域可以使用NSEC3以及NSEC记录来拒绝存在。选择该机制是为了保护RFC 5155之前的实现不会遇到他们不知道的资源记录。本文档未定义此类算法别名。
A DNSSEC validator that implements RSA/SHA-2 MUST be able to validate negative answers in the form of both NSEC and NSEC3 with hash algorithm 1, as defined in [RFC5155]. An authoritative server that does not implement NSEC3 MAY still serve zones that use RSA/SHA-2 with NSEC denial of existence.
实现RSA/SHA-2的DNSSEC验证器必须能够使用[RFC5155]中定义的哈希算法1验证NSEC和NSEC3形式的否定答案。未实现NSEC3的权威服务器可能仍在为使用RSA/SHA-2且NSEC拒绝存在的区域提供服务。
Given a private key with the following values (in Base64):
给定具有以下值的私钥（在Base64中）：
Private-key-format: v1.2
Algorithm: 8 (RSASHA256)
Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
PublicExponent: AQAB
PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
Private-key-format: v1.2
Algorithm: 8 (RSASHA256)
Modulus: wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm
idzC2RnhwCC293hCzw+TFR2nqn8OVSY5t2Q==
PublicExponent: AQAB
PrivateExponent: UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN+i/
HAam+97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ==
Prime1: 4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk=
Prime2: 2zZpBE8ZXVnL74QjG4zINlDfH+EOEtjJJ3RtaYDugvE=
Exponent1: G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk=
Exponent2: GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE=
Coefficient: icQdNRjlZGPmuJm2TIadubcO8X7V4y07aVhX464tx8Q=
The DNSKEY record for this key would be:
此密钥的DNSKEY记录为：
example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
example.net. 3600 IN DNSKEY (256 3 8 AwEAAcFcGsaxxdgiuuGmCkVI
my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P
kxUdp6p/DlUmObdk= );{id = 9033 (zsk), size = 512b}
With this key, sign the following RRSet, consisting of 1 A record:
使用此键，签署以下RRSet，包括1 A记录：
www.example.net. 3600 IN A 192.0.2.91
www.example.net。在192.0.2.91中为3600
If the inception date is set at 00:00 hours on January 1st, 2000, and the expiration date at 00:00 hours on January 1st, 2030, the following signature should be created:
如果起始日期设置为2000年1月1日00:00，到期日期设置为2030年1月1日00:00，则应创建以下签名：
www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
cFYK/lPtPiVYP4bwg==);{id = 9033}
www.example.net. 3600 IN RRSIG (A 8 3 3600 20300101000000
20000101000000 9033 example.net. kRCOH6u7l0QGy9qpC9
l1sLncJcOKFLJ7GhiUOibu4teYp5VE9RncriShZNz85mwlMgNEa
cFYK/lPtPiVYP4bwg==);{id = 9033}
Given a private key with the following values (in Base64):
给定具有以下值的私钥（在Base64中）：
Private-key-format: v1.2
Algorithm: 10 (RSASHA512)
Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
jXZlNKdyit99waaE4s=
PublicExponent: AQAB
PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
SEIAsrB043XzGrKIVE=
Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
/Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
Private-key-format: v1.2
Algorithm: 10 (RSASHA512)
Modulus: 0eg1M5b563zoq4k5ZEOnWmd2/BvpjzedJVdfIsDcMuuhE5SQ3pf
Q7qmdaeMlC6Nf8DKGoUPGPXe06cP27/WRODtxXquSUytkO0kJDk
8KX8PtA0+yBWwy7UnZDyCkynO00Uuk8HPVtZeMO1pHtlAGVnc8V
jXZlNKdyit99waaE4s=
PublicExponent: AQAB
PrivateExponent: rFS1IPbJllFFgFc33B5DDlC1egO8e81P4fFadODbp56V7sphKa6
AZQCx8NYAew6VXFFPAKTw41QdHnK5kIYOwxvfFDjDcUGza88qbj
yrDPSJenkeZbISMUSSqy7AMFzEolkk6WSn6k3thUVRgSlqDoOV3
SEIAsrB043XzGrKIVE=
Prime1: 8mbtsu9Tl9v7tKSHdCIeprLIQXQLzxlSZun5T1n/OjvXSUtvD7x
nZJ+LHqaBj1dIgMbCq2U8O04QVcK3TS9GiQ==
Prime2: 3a6gkfs74d0Jb7yL4j4adAif4fcp7ZrGt7G5NRVDDY/Mv4TERAK
Ma0TKN3okKE0A7X+Rv2K84mhT4QLDlllEcw==
Exponent1: v3D5A9uuCn5rgVR7wgV8ba0/KSpsdSiLgsoA42GxiB1gvvs7gJM
MmVTDu/ZG1p1ZnpLbhh/S/Qd/MSwyNlxC+Q==
Exponent2: m+ezf9dsDvYQK+gzjOLWYeKq5xWYBEYFGa3BLocMiF4oxkzOZ3J
PZSWU/h1Fjp5RV7aPP0Vmx+hNjYMPIQ8Y5w==
Coefficient: Je5YhYpUron/WdOXjxNAxDubAp3i5X7UOUfhJcyIggqwY86IE0Q
/Bk0Dw4SC9zxnsimmdBXW2Izd8Lwuk8FQcQ==
The DNSKEY record for this key would be:
此密钥的DNSKEY记录为：
example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
);{id = 3740 (zsk), size = 1024b}
example.net. 3600 IN DNSKEY (256 3 10 AwEAAdHoNTOW+et86KuJOWRD
p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX/AyhqFD
xj13tOnD9u/1kTg7cV6rklMrZDtJCQ5PCl/D7QNPsgVsMu1J2Q8g
pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL
);{id = 3740 (zsk), size = 1024b}
With this key, sign the following RRSet, consisting of 1 A record:
使用此键，签署以下RRSet，包括1 A记录：
www.example.net. 3600 IN A 192.0.2.91
www.example.net。在192.0.2.91中为3600
If the inception date is set at 00:00 hours on January 1st, 2000, and the expiration date at 00:00 hours on January 1st, 2030, the following signature should be created:
如果起始日期设置为2000年1月1日00:00，到期日期设置为2030年1月1日00:00，则应创建以下签名：
www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
=);{id = 3740}
www.example.net. 3600 IN RRSIG (A 10 3 3600 20300101000000
20000101000000 3740 example.net. tsb4wnjRUDnB1BUi+t
6TMTXThjVnG+eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa
eUw1ep94PzEWzr0iGYgZBWm/zpq+9fOuagYJRfDqfReKBzMweOL
DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw
=);{id = 3740}
This document updates the IANA registry "DNS SECURITY ALGORITHM NUMBERS -- per [RFC4035]" (http://www.iana.org/protocols). The following entries are added to the registry:
本文档更新IANA注册表“DNS安全算法编号——依据[RFC4035]”(http://www.iana.org/protocols). 将以下条目添加到注册表中：
Zone Trans. Value Description Mnemonic Signing Sec. References 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 10 RSA/SHA-512 RSASHA512 Y * RFC 5702
区域转换。值描述助记符签名秒。参考文献8 RSA/SHA-256 RSASA256 Y*RFC 5702 10 RSA/SHA-512 RSASA512 Y*RFC 5702
* There has been no determination of standardization of the use of this algorithm with Transaction Security.
* 目前还没有确定该算法与事务安全性的标准化使用。
Users of DNSSEC are encouraged to deploy SHA-2 as soon as software implementations allow for it. SHA-2 is widely believed to be more resilient to attack than SHA-1, and confidence in SHA-1's strength is being eroded by recently announced attacks. Regardless of whether or not the attacks on SHA-1 will affect DNSSEC, it is believed (at the time of this writing) that SHA-2 is the better choice for use in DNSSEC records.
鼓励DNSSEC用户在软件实现允许的情况下尽快部署SHA-2。人们普遍认为，SHA-2比SHA-1更能抵御攻击，人们对SHA-1实力的信心正在被最近宣布的攻击所削弱。无论对SHA-1的攻击是否会影响DNSSEC，都认为（在撰写本文时）SHA-2是DNSSEC记录中使用的更好选择。
SHA-2 is considered sufficiently strong for the immediate future, but predictions about future development in cryptography and cryptanalysis are beyond the scope of this document.
SHA-2被认为在不久的将来足够强大，但对密码术和密码分析未来发展的预测超出了本文的范围。
The signature scheme RSASSA-PKCS1-v1_5 is chosen to match the one used for RSA/SHA-1 signatures. This should ease implementation of the new hashing algorithms in DNSSEC software.
选择签名方案RSASSA-PKCS1-v1_5以匹配用于RSA/SHA-1签名的方案。这将简化DNSSEC软件中新哈希算法的实现。
Since each RRSet MUST be signed with each algorithm present in the DNSKEY RRSet at the zone apex (see Section 2.2 of [RFC4035]), a malicious party cannot filter out the RSA/SHA-2 RRSIG and force the validator to use the RSA/SHA-1 signature if both are present in the zone. This should provide resilience against algorithm downgrade attacks, if the validator supports RSA/SHA-2.
由于必须使用区域顶点的DNSKEY RRSet中存在的每个算法对每个RRSet进行签名（请参见[RFC4035]第2.2节），因此恶意方无法过滤掉RSA/SHA-2 RRSIG，并强制验证器使用RSA/SHA-1签名（如果两者都存在于区域中）。如果验证器支持RSA/SHA-2，这将提供对算法降级攻击的恢复能力。
This document is a minor extension to [RFC4034]. Also, we try to follow the documents [RFC3110] and [RFC4509] for consistency. The authors of and contributors to these documents are gratefully acknowledged for their hard work.
本文档是[RFC4034]的一个小扩展。此外，为了保持一致性，我们尝试遵循文档[RFC3110]和[RFC4509]。感谢这些文件的作者和贡献者的辛勤工作。
The following people provided additional feedback and text: Jaap Akkerhuis, Mark Andrews, Roy Arends, Rob Austein, Francis Dupont, Miek Gieben, Alfred Hoenes, Paul Hoffman, Peter Koch, Scott Rose, Michael St. Johns, and Wouter Wijngaards.
以下人员提供了额外的反馈和文本：雅普·阿克赫斯、马克·安德鲁斯、罗伊·阿伦兹、罗布·奥斯汀、弗朗西斯·杜邦、米克·吉本、阿尔弗雷德·霍恩斯、保罗·霍夫曼、彼得·科赫、斯科特·罗斯、迈克尔·圣约翰和沃特·维恩加德斯。
[FIPS.180-3.2008] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-3, October 2008.
[FIPS.180-3.2008]国家标准与技术研究所，“安全哈希标准”，FIPS PUB 180-3，2008年10月。
[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月。
[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月。
[NIST800-57] Barker, E., Barker, W., Burr, W., Polk, W., and M. Smid, "Recommendations for Key Management", NIST SP 800-57, March 2007.
[NIST 800-57]Barker，E.，Barker，W.，Burr，W.，Polk，W.，和M.Smid，“关键管理建议”，NIST SP 800-57，2007年3月。
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447, February 2003.
[RFC3447]Jonsson，J.和B.Kaliski，“公钥密码标准（PKCS）#1:RSA密码规范版本2.1”，RFC 3447，2003年2月。
[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月。
Author's Address
作者地址
Jelte Jansen NLnet Labs Science Park 140 1098 XG Amsterdam NL
Jelte Jansen NLnet实验室科学园140 1098 XG阿姆斯特丹NL
EMail: jelte@NLnetLabs.nl
URI: http://www.nlnetlabs.nl/
EMail: jelte@NLnetLabs.nl
URI: http://www.nlnetlabs.nl/