[要約] RFC 3110は、DNSでRSA/SHA-1 SIGsとRSA KEYsを使用する方法についての標準化された仕様です。このRFCの目的は、DNSにおけるセキュリティと認証の向上を促進することです。
Network Working Group D. Eastlake 3rd
Request for Comments: 3110 Motorola
Obsoletes: 2537 May 2001
Category: Standards Track
RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
ドメイン名システム（DNS）のRSA/SHA-1シグとRSAキー
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) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document describes how to produce RSA/SHA1 SIG resource records (RRs) in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2.
このドキュメントでは、セクション3でRSA/SHA1 SIGリソースレコード（RRS）を作成する方法について説明し、RFC 2537を完全に置き換えるために、セクション2でRSAキーRRを生成する方法について説明します。
Since the adoption of a Proposed Standard for RSA signatures in the DNS (Domain Name Space), advances in hashing have been made. A new DNS signature algorithm is defined to make these advances available in SIG RRs. The use of the previously specified weaker mechanism is deprecated. The algorithm number of the RSA KEY RR is changed to correspond to this new SIG algorithm. No other changes are made to DNS security.
DNS（ドメイン名スペース）におけるRSA署名の提案された基準が採用されて以来、ハッシュの進歩が行われています。新しいDNS署名アルゴリズムが定義されており、これらの進歩をSIG RRSで利用可能にします。以前に指定された弱いメカニズムの使用は非推奨です。RSAキーRRのアルゴリズム番号は、この新しいSIGアルゴリズムに対応するように変更されます。DNSセキュリティに他の変更は行われていません。
Acknowledgements
謝辞
Material and comments from the following have been incorporated and are gratefully acknowledged:
以下からの資料とコメントは組み込まれており、感謝されています。
Olafur Gudmundsson
Olafur Gudmundsson
The IESG
IESG
Charlie Kaufman
チャーリー・カウフマン
Steve Wang
スティーブ・ワン
Table of Contents
目次
1. Introduction................................................... 2
2. RSA Public KEY Resource Records................................ 3
3. RSA/SHA1 SIG Resource Records.................................. 3
4. Performance Considerations..................................... 4
5. IANA Considerations............................................ 5
6. Security Considerations........................................ 5
References........................................................ 5
Author's Address.................................................. 6
Full Copyright Statement.......................................... 7
The Domain Name System (DNS) is the global hierarchical replicated distributed database system for Internet addressing, mail proxy, and other information [RFC1034, 1035, etc.]. The DNS has been extended to include digital signatures and cryptographic keys as described in [RFC2535]. Thus the DNS can now be secured and used for secure key distribution.
ドメイン名システム（DNS）は、インターネットアドレス指定、メールプロキシ、およびその他の情報[RFC1034、1035など]用のグローバル階層複製分散データベースシステムです。DNSは、[RFC2535]で説明されているように、デジタル署名と暗号化キーを含むように拡張されています。したがって、DNSを保護し、安全なキー分布に使用できるようになりました。
Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier, FIP180] in this document.
このドキュメントでは、RSAおよびSHA-1アルゴリズムに精通している[Schneier、FIP180]と想定されています。
RFC 2537 described how to store RSA keys and RSA/MD5 based signatures in the DNS. However, since the adoption of RFC 2537, continued cryptographic research has revealed hints of weakness in the MD5 [RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm [FIP180], which produces a larger hash, has been developed. By now there has been sufficient experience with SHA1 that it is generally acknowledged to be stronger than MD5. While this stronger hash is probably not needed today in most secure DNS zones, critical zones such a root, most top level domains, and some second and third level domains, are sufficiently valuable targets that it would be negligent not to provide what are generally agreed to be stronger mechanisms. Furthermore, future advances in cryptanalysis and/or computer speeds may require a stronger hash everywhere. In addition, the additional computation required by SHA1 above that required by MD5 is insignificant compared with the computational effort required by the RSA modular exponentiation.
RFC 2537は、DNSにRSAキーとRSA/MD5ベースの署名を保存する方法について説明しました。しかし、RFC 2537の採用以来、継続的な暗号化研究により、RFC 2537で使用されるMD5 [RFC1321]アルゴリズムの弱さのヒントが明らかになりました。今では、SHA1で十分な経験があり、一般的にMD5よりも強いと認められています。この強いハッシュはおそらくほとんどの安全なDNSゾーンでは必要ありませんが、ルート、ほとんどのトップレベルドメイン、およびいくつかの2番目と第3レベルのドメインなどの重要なゾーンは、一般的に合意されたものを提供しないことは過失ではないほど貴重なターゲットです。より強力なメカニズムになること。さらに、暗号化および/またはコンピューター速度の将来の進歩には、どこでもより強力なハッシュが必要になる場合があります。さらに、MD5が必要とする上記のSHA1が必要とする追加の計算は、RSAモジュラー指数が必要とする計算作業と比較して重要ではありません。
This document describes how to produce RSA/SHA1 SIG RRs in Section 3 and, so as to completely replace RFC 2537, describes how to produce RSA KEY RRs in Section 2.
このドキュメントでは、セクション3でRSA/SHA1 SIG RRSを生成する方法について説明し、RFC 2537を完全に置き換えるために、セクション2でRSAキーRRを生成する方法について説明します。
Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537 is NOT RECOMMENDED.
SHA1を使用したDNSでのRSAアルゴリズムの実装は、DNSSECには必須です。RFC 2537で説明されているRSA/MD5 SIG RRSの生成は推奨されません。
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119.
このドキュメントの「必須」、「必須」、「必要」、「推奨」、「推奨されない」、「5月」は、RFC 2119で説明されているように解釈されます。
RSA public keys are stored in the DNS as KEY RRs using algorithm number 5 [RFC2535]. The structure of the algorithm specific portion of the RDATA part of such RRs is as shown below.
RSAパブリックキーは、アルゴリズム番号5 [RFC2535]を使用して、キーRRSとしてDNSに保存されます。このようなRRSのRDATA部分のアルゴリズム固有部分の構造は、以下に示すように。
Field Size
----- ----
exponent length 1 or 3 octets (see text)
exponent as specified by length field
modulus remaining space
For interoperability, the exponent and modulus are each limited to 4096 bits in length. The public key exponent is a variable length unsigned integer. Its length in octets is represented as one octet if it is in the range of 1 to 255 and by a zero octet followed by a two octet unsigned length if it is longer than 255 bytes. The public key modulus field is a multiprecision unsigned integer. The length of the modulus can be determined from the RDLENGTH and the preceding RDATA fields including the exponent. Leading zero octets are prohibited in the exponent and modulus.
相互運用性のために、指数と弾性率の長さはそれぞれ4096ビットに制限されています。公開キーの指数は、可変長さ符号なし整数です。オクテットのその長さは、1〜255の範囲である場合は1オクテットとして表され、ゼロオクテットが255バイトより長い場合は2オクテットの符号なしの長さが続きます。公開キーモジュラスフィールドは、複数の署名されていない整数です。弾性率の長さは、指数を含むrdlengthと前のrdataフィールドから決定できます。指数と弾性率では、先頭のゼロオクテットが禁止されています。
Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this algorithm number (rather than the algorithm number specified in the obsoleted RFC 2537).
注：RSA/SHA1 DNS署名で使用する重要なRRSは、このアルゴリズム番号を使用する必要があります（廃止されたRFC 2537で指定されたアルゴリズム番号ではありません）。
Note: This changes the algorithm number for RSA KEY RRs to be the same as the new algorithm number for RSA/SHA1 SIGs.
注：これにより、RSAキーRRSのアルゴリズム番号がRSA/SHA1 SIGの新しいアルゴリズム番号と同じに変更されます。
RSA/SHA1 signatures are stored in the DNS using SIG resource records (RRs) with algorithm number 5.
RSA/SHA1署名は、アルゴリズム番号5のSIGリソースレコード（RRS）を使用してDNSに保存されます。
The signature portion of the SIG RR RDATA area, when using the RSA/SHA1 algorithm, is calculated as shown below. The data signed is determined as specified in RFC 2535. See RFC 2535 for fields in the SIG RR RDATA which precede the signature itself.
RSA/SHA1アルゴリズムを使用する場合、SIG RR RRDATA領域の署名部分を以下に示すように計算します。署名されたデータは、RFC 2535で指定されているように決定されます。署名自体の前にあるSIG RR RDATAのフィールドについては、RFC 2535を参照してください。
hash = SHA1 ( data )
ハッシュ= sha1（data）
signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
where SHA1 is the message digest algorithm documented in [FIP180], "|" is concatenation, "e" is the private key exponent of the signer, and "n" is the modulus of the signer's public key. 01, FF, and 00 are fixed octets of the corresponding hexadecimal value. "prefix" is the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1 [RFC2437], that is,
ここで、SHA1は[FIP180]、 "|"に文書化されたメッセージダイジェストアルゴリズムです。連結は、「E」は署名者の秘密キーの指数であり、「n」は署名者の公開鍵の弾性率です。01、ff、および00は、対応する六文学値の固定オクテットです。「プレフィックス」は、PKCS1 [RFC2437]に必要なASN.1 BER SHA1アルゴリズム指定のプレフィックスです。
hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
ヘックス30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14
This prefix is included to make it easier to use standard cryptographic libraries. The FF octet MUST be repeated the maximum number of times such that the value of the quantity being exponentiated is one octet shorter than the value of n.
このプレフィックスは、標準の暗号化ライブラリを使いやすくするために含まれています。FFオクテットは、指数化される量の値がnの値よりも1オクテットより短いものになるように、最大回数を繰り返す必要があります。
(The above specifications are identical to the corresponding parts of Public Key Cryptographic Standard #1 [RFC2437].)
（上記の仕様は、公開キーの暗号標準＃1 [RFC2437]の対応する部分と同じです。）
The size of "n", including most and least significant bits (which will be 1) MUST be not less than 512 bits and not more than 4096 bits. "n" and "e" SHOULD be chosen such that the public exponent is small. These are protocol limits. For a discussion of key size see RFC 2541.
最も有意なビット（1になる）を含む「n」のサイズ（1となる）は、512ビット以上、4096ビット以下でなければなりません。「n」と「e」は、公開指数が小さいように選択する必要があります。これらはプロトコル制限です。キーサイズの議論については、RFC 2541を参照してください。
Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
RSA/SHA1アルゴリズムの署名では、先行ゼロバイトが許可されています。
General signature generation speeds are roughly the same for RSA and DSA [RFC2536]. With sufficient pre-computation, signature generation with DSA is faster than RSA. Key generation is also faster for DSA. However, signature verification is an order of magnitude slower with DSA when the RSA public exponent is chosen to be small as is recommended for KEY RRs used in domain name system (DNS) data authentication.
一般的な署名生成速度は、RSAとDSA [RFC2536]でほぼ同じです。十分な事前計算により、DSAを使用した署名生成はRSAよりも高速です。Key Generationは、DSAの方が速いです。ただし、DSAの署名検証は、ドメイン名システム（DNS）データ認証で使用される主要なRRSに推奨されるように、RSAパブリックエクスポーネントが小さいように選択される場合、DSAで数桁遅くなります。
A public exponent of 3 minimizes the effort needed to verify a signature. Use of 3 as the public exponent is weak for confidentiality uses since, if the same data can be collected encrypted under three different keys with an exponent of 3 then, using the Chinese Remainder Theorem [NETSEC], the original plain text can be easily recovered. If a key is known to be used only for authentication, as is the case with DNSSEC, then an exponent of 3 is acceptable. However other applications in the future may wish to leverage DNS distributed keys for applications that do require confidentiality. For keys which might have such other uses, a more conservative choice would be 65537 (F4, the fourth fermat number).
3の公開指数は、署名を確認するために必要な努力を最小限に抑えます。パブリック指数として3の使用は機密性の使用には弱いため、同じデータを3の異なるキーの下で暗号化できた場合、中国の残りの定理[netsec]を使用して、元のプレーンテキストを簡単に回復できるため、。キーが認証にのみ使用されることが知られている場合、DNSSECの場合のように、3の指数は許容されます。ただし、将来の他のアプリケーションは、機密性が必要なアプリケーションのDNS分散キーを活用したい場合があります。そのような他の用途があるかもしれないキーの場合、より保守的な選択は65537（F4、4番目のFermat番号）です。
Current DNS implementations are optimized for small transfers, typically less than 512 bytes including DNS overhead. Larger transfers will perform correctly and extensions have been standardized [RFC2671] to make larger transfers more efficient, it is still advisable at this time to make reasonable efforts to minimize the size of KEY RR sets stored within the DNS consistent with adequate security. Keep in mind that in a secure zone, at least one authenticating SIG RR will also be returned.
現在のDNS実装は、通常、DNSオーバーヘッドを含む512バイト未満で、小さな転送用に最適化されています。より大きな転送が正しく機能し、拡張機能が標準化され[RFC2671]、より大きな転送をより効率的にすることができますが、適切なセキュリティと一致するDNS内に保存されているキーRRセットのサイズを最小限に抑えるために合理的な努力をすることが依然として推奨されています。安全なゾーンでは、少なくとも1つの認証SIG RRも返されることに注意してください。
The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and RSA KEY RRs.
DNSSECアルゴリズム番号5は、RSA/SHA1 SIG RRSおよびRSAキーRRに割り当てられています。
Many of the general security considerations in RFC 2535 apply. Keys retrieved from the DNS should not be trusted unless (1) they have been securely obtained from a secure resolver or independently verified by the user and (2) this secure resolver and secure obtainment or independent verification conform to security policies acceptable to the user. As with all cryptographic algorithms, evaluating the necessary strength of the key is essential and dependent on local policy. For particularly critical applications, implementers are encouraged to consider the range of available algorithms and key sizes. See also RFC 2541, "DNS Security Operational Considerations".
RFC 2535の一般的なセキュリティ上の考慮事項の多くが適用されます。DNSから取得されたキーは、（1）安全にリゾルバーから安全に取得されるか、ユーザーによって独立して検証されていない場合を除き、信頼しないでください。すべての暗号化アルゴリズムと同様に、キーの必要な強さを評価することは不可欠であり、ローカルポリシーに依存します。特に重要なアプリケーションのために、実装者は、利用可能なアルゴリズムとキーサイズの範囲を考慮することをお勧めします。RFC 2541、「DNSセキュリティ運用上の考慮事項」も参照してください。
References
参考文献
[FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS PUB 180-1, 17 Apr 1995.
[FIP180]米国商務省、「Secure Hash Standard」、Fips Pub 180-1、1995年4月17日。
[NETSEC] Network Security: PRIVATE Communications in a PUBLIC World, Charlie Kaufman, Radia Perlman, & Mike Speciner, Prentice Hall Series in Computer Networking and Distributed Communications, 1995.
[NETSEC]ネットワークセキュリティ：公共界のプライベートコミュニケーション、チャーリーカウフマン、ラディアパールマン、マイクの仕様、コンピューターネットワーキングおよび分散通信のプレンティスホールシリーズ、1995年。
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[RFC1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[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月。
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.
[RFC2437] Kaliski、B。and J. Staddon、「PKCS＃1：RSA暗号仕様バージョン2.0」、RFC 2437、1998年10月。
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.
[RFC2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.
[RFC2536] EastLake、D。、「DSA Keys and Sigs in the Domain Name System（DNS）」、RFC 2536、1999年3月。
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)", RFC 2537, March 1999.
[RFC2537] Eastlake、D。、「RSA/MD5キーとドメイン名システム（DNS）のキーとSIG」、RFC 2537、1999年3月。
[RFC2541] Eastlake, D., "DNS Security Operational Considerations", RFC 2541, March 1999.
[RFC2541] Eastlake、D。、「DNSセキュリティ運用上の考慮事項」、RFC 2541、1999年3月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[Schneier] Bruce Schneier, "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996, John Wiley and Sons, ISBN 0-471-11709-9.
[Schneier] Bruce Schneier、「Applied Cryptography Second Edition：Protocols、Algorithms、and Source Code in C in Cの」、1996年、John Wiley and Sons、ISBN 0-471-11709-9。
Author's Address
著者の連絡先
Donald E. Eastlake 3rd Motorola 155 Beaver Street Milford, MA 01757 USA
ドナルドE.イーストレイク第3モトローラ155ビーバーストリートミルフォード、マサチューセッツ州01757 USA
Phone: +1-508-261-5434 (w)
+1-508-634-2066 (h)
Fax +1-508-261-4777 (w)
EMail: Donald.Eastlake@motorola.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があり、それについてコメントまたは説明する派生作品、またはその実装を支援することができます。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。