[要約] RFC 5702は、DNSSECでのSHA-2アルゴリズムの使用に関するガイドラインです。目的は、DNSKEYとRRSIGリソースレコードでRSAとSHA-2を組み合わせて使用する方法を提供することです。
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
DNSKEYのRSAを使用したSHA-2アルゴリズムの使用およびDNSSECのRRSIGリソースレコード
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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-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のコレクションを参照するために使用されます。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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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リソースレコード（RRS）に保存されます。
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リソースレコード（RRS）に保存されます。
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)
hash = sha-xxx（data）
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].
ここでは、FIPS Pub 180-3で指定されているように、使用されるアルゴリズムに応じて、XXXは256または512です。「データ」は、[RFC4034]で指定されているように、署名されたリソースレコードセットのワイヤー形式データです。
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」は、対応する16進数の固定オクテットです。「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）、およびPKCS＃1 V2.1（[RFC34472のセクション9.2のセクション9.2）のRSASSA-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]:
接頭辞は、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リソースレコード（RRS）を使用して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.
[RFC5155]で定義されているように、RSA/SHA-2を実装するDNSSECバリエーターは、ハッシュアルゴリズム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=
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}
With this key, sign the following RRSet, consisting of 1 A record:
このキーを使用して、次のRRSetに署名します。
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}
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==
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。
With this key, sign the following RRSet, consisting of 1 A record:
このキーを使用して、次のRRSetに署名します。
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}
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
* 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.
各RRSETは、ゾーンアペックスのDNSKEY 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.
次の人々は、追加のフィードバックとテキストを提供しました：Jaap Akkerhuis、Mark Andrews、Roy Arends、Rob Austein、Francis Dupont、Miek Gieben、Alfred Hoenes、Paul Hoffman、Peter Koch、Scott Rose、Michael St. Johns、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]国立標準技術研究所、「Secure Hash Standard」、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。、「RSA/SHA-1 SIGSおよび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] 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 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] 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、「Public-Key Cryptography Standards（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。、「DNSSEC Delogation Signer（DS）Resource Records（RRS）でのSHA-256の使用」、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 Security（DNSSEC）は認証された存在拒否」、RFC 5155、2008年3月。
Author's Address
著者の連絡先
Jelte Jansen NLnet Labs Science Park 140 1098 XG Amsterdam NL
Jelte Jansen NLNet Labs Science Park 140 1098 XG AMSTERDAM NL
EMail: jelte@NLnetLabs.nl
URI: http://www.nlnetlabs.nl/