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
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).
この文書では、ドメインネームシステムセキュリティ拡張（RFC 4033、RFC 4034、およびRFC 4035）で使用するRSA / SHA-256およびRSA / SHA-512 DNSKEYとRRSIGリソースレコードを作成する方法について説明します。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション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
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）は、インターネットネーミングのためのグローバルな、階層的な分散データベースです。 DNSは、そのデータの真正性と完全性を検証するための暗号鍵とデジタル署名を使用するように拡張されました。 [RFC4033]、[RFC4034]、および[RFC4035]はDNSSECと呼ばれるこれらのDNSセキュリティ拡張機能を、説明します。
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-2を使用してグループ化するRSA / SHA-256およびRSA / SHA-512、のために行きます。
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の集合を指すために使用されます。 SHA-224およびSHA-384をDNSSECで使用されていないため、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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]はDNSSEC署名のためのRSA / SHA-1の使用を記載しています。
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公開鍵アルゴリズム番号8とDNSKEYリソースレコード（RR）に格納されています。
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公開鍵アルゴリズム番号10とDNSKEYリソースレコード（RR）に格納されています。
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の署名方式に従い、次のように計算されます。署名データに先行RDATAフィールドの値は[RFC4034]で指定されています。
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は、FIPS PUB 180-3のに指定され、使用されるアルゴリズムに応じて、256または512のいずれかです。 「データ」は、[RFC4034]で指定されるように、署名されているリソースレコードセットのワイヤー形式のデータです。
signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
署名=（00 | 01 | FF * | 00 |プレフィックス|ハッシュ）** 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」は、16進数の値を対応する固定されたオクテットです。 「e」は署名RSAキーのプライベートな指数です。 「n」は署名鍵の公開係数です。括弧内の連結された用語の全長が署名者の公開鍵（「N」）のモジュラスの長さに等しくなるようにFFオクテットは、時間の正確な数を繰り返さなければなりません。
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でRSASSA-PKCS1-v1_5の仕様から直接取得される（セクション8.2 [RFC3447]）、およびEMSA-PKCS1-v1_5のエンコードPKCS＃1 V2.1（[RFC3447のセクション9.2で]）。異なるアルゴリズムのための接頭辞は、以下に指定されています。
RSA/SHA-256 signatures are stored in the DNS using RRSIG resource records (RRs) with algorithm number 8.
RSA / SHA-256署名は、アルゴリズム番号8とRRSIGリソースレコード（RR）を使用して、DNSに格納されています。
The prefix is the ASN.1 DER SHA-256 algorithm designator prefix, as specified in PKCS #1 v2.1 [RFC3447]:
プレフィックスは、PKCS＃1 V2.1 [RFC3447]で指定されるように、ASN.1 DER SHA-256アルゴリズム指定子プリフィックスです。
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リソースレコード（RR）を使用して、DNSに格納されています。
The prefix is the ASN.1 DER SHA-512 algorithm designator prefix, as specified in PKCS #1 v2.1 [RFC3447]:
プレフィックスは、PKCS＃1 V2.1 [RFC3447]で指定されるように、ASN.1 DER SHA-512アルゴリズム指定子プリフィックスです。
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 [NIST800-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を実装していない権限のあるサーバーは、まだ存在のNSEC拒否してRSA / SHA-2を使用したゾーンを果たすことができます。
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=
秘密鍵形式：V1.2アルゴリズム：8（RSASHA256）モジュラス：wVwaxrHF2CK64aYKRUibLiH30KpPuPBjel7E8ZydQW1HYWHfoGm idzC2RnhwCC293hCzw + TFR2nqn8OVSY5t2Q == PublicExponent：AQAB PrivateExponent：UR44xX6zB3eaeyvTRzmskHADrPCmPWnr8dxsNwiDGHzrMKLN + I / HAAM + 97HxIKVWNDH2ba9Mf1SA8xu9dcHZAQ == Prime1：4c8IvFu1AVXGWeFLLFh5vs7fbdzdC6U82fduE6KkSWk = Prime2：2zZpBE8ZXVnL74QjG4zINlDfH + EOEtjJJ3RtaYDugvE = Exponent1：G2xAPFfK0KGxGANDVNxd1K1c9wOmmJ51mGbzKFFNMFk = Exponent2：GYxP1Pa7CAwtHm8SAGX594qZVofOMhgd6YFCNyeVpKE =係数：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 DNSKEY IN（256 3~8 AwEAAcFcGsaxxdgiuuGmCkVI my4h99CqT7jwY3pexPGcnUFtR2Fh36BponcwtkZ4cAgtvd4Qs8P kxUdp6p / DlUmObdk =）; {ID = 9033（ZSK）、サイズ= 512B}
With this key, sign the following RRSet, consisting of 1 A record:
このキーでは、1のレコードから成る、以下の資源レコード集合に署名：
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:
開始日が1月1日、2030に00:00で1月1日、2000、および有効期限の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。 RRSIG IN 3600（3 3600 20300101000000 20000101000000 9033 8 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==
秘密鍵形式：V1.2アルゴリズム：10（RSASHA512）モジュラス：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 ==係数：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 DNSKEY IN（256 3 10 AwEAAdHoNTOW + et86KuJOWRD p1pndvwb6Y83nSVXXyLA3DLroROUkN6X0O6pnWnjJQujX / AyhqFD xj13tOnD9u / 1kTg7cV6rklMrZDtJCQ5PCl / D7QNPsgVsMu1J2Q8g pMpztNFLpPBz1bWXjDtaR7ZQBlZ3PFY12ZTSncorffcGmhOL）; {ID = 3740（ZSK）、サイズ= 1024B}
With this key, sign the following RRSet, consisting of 1 A record:
このキーでは、1のレコードから成る、以下の資源レコード集合に署名：
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:
開始日が1月1日、2030に00:00で1月1日、2000、および有効期限の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 RRSIG（10 3 3600 20300101000000 20000101000000 3740 example.net tsb4wnjRUDnB1BUi + T 6TMTXThjVnG + eCkWqjvvjhzQL1d0YRoOe0CbxrVDYd0xDtsuJRa eUw1ep94PzEWzr0iGYgZBWm / zpq + 9fOuagYJRfDqfReKBzMweOL DiNa8iP5g9vMhpuv6OPlvpXwm9Sa9ZXIbNl1MBGk0fthPgxdDLw =。）IN; {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:
" - [RFC4035]あたりのDNSセキュリティアルゴリズム番号"（http://www.iana.org/protocols）この文書は、IANAレジストリを更新します。次のエントリがレジストリに追加されます。
Zone Trans. Value Description Mnemonic Signing Sec. References 8 RSA/SHA-256 RSASHA256 Y * RFC 5702 10 RSA/SHA-512 RSASHA512 Y * RFC 5702
ゾーントランス。値説明ニーモニックは、SECに署名します。参考文献8 RSA / SHA-256 RSASHA256 Y * RFC 5702 10 RSA / SHA-512 RSASHA512 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.
各資源レコード集合は、（[RFC4035]のセクション2.2を参照）、悪意のある当事者は、RSA / SHA-2 RRSIGをフィルタリングし、RSAを/使用するバリデータを強制することができないゾーンの頂点でDNSKEY資源レコード集合内の各アルゴリズムが存在して署名されなければならないので両方のゾーンに存在する場合、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.
ヤープAkkerhuis、マーク・アンドリュース、ロイ・アレンズ、ロブAusteinと、フランシスデュポン、Miek Gieben、アルフレッドHoenes、ポール・ホフマン、ピーター・コッホ、スコット・ローズ、マイケル・セントジョンズ、とは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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]イーストレーク、D.、 "ドメインネームシステムにおけるRSA / SHA-1のSIGとRSA鍵（DNS）"、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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年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]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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]バーカー、E.、バーカー、W.、バリ、W.、ポーク、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]ジョンソン、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.、RFC 4509、2006年5月 "DNSSEC委任署名者（DS）リソースレコード（RR）でSHA-256の使用"。
[RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
[RFC5155]ローリー、B.、シッソン、G.、アレンズ、R.、およびD. Blacka、 "DNSセキュリティ（DNSSEC）存在のハッシュ認証拒否"、RFC 5155、2008年3月。
Author's Address
著者のアドレス
Jelte Jansen NLnet Labs Science Park 140 1098 XG Amsterdam NL
JelteヤンセンNLnet Labsのサイエンスパーク140 1098 XGアムステルダムNL
EMail: jelte@NLnetLabs.nl URI: http://www.nlnetlabs.nl/
電子メール：jelte@NLnetLabs.nl URI：http://www.nlnetlabs.nl/