[要約] RFC 2537は、DNSでRSA/MD5キーと署名を使用する方法について説明しています。このRFCの目的は、DNSセキュリティの向上と、データの信頼性と完全性の確保です。

Network Working Group                                        D. Eastlake
Request for Comments: 2537                                           IBM
Category: Standards Track                                     March 1999
        

RSA/MD5 KEYs and SIGs in the Domain Name System (DNS)

ドメイン名システムのRSA/MD5キーとSIG(DNS)

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 (1999). All Rights Reserved.

Copyright(c)The Internet Society(1999)。全著作権所有。

Abstract

概要

A standard method for storing RSA keys and and RSA/MD5 based signatures in the Domain Name System is described which utilizes DNS KEY and SIG resource records.

DNSキーおよびSIGリソースレコードを利用するドメイン名システムにRSAキーとRSA/MD5ベースの署名を保存するための標準的な方法が記載されています。

Table of Contents

目次

   Abstract...................................................1
   1. Introduction............................................1
   2. RSA Public KEY Resource Records.........................2
   3. RSA/MD5 SIG Resource Records............................2
   4. Performance Considerations..............................3
   5. Security Considerations.................................4
   References.................................................4
   Author's Address...........................................5
   Full Copyright Statement...................................6
        
1. Introduction
1. はじめに

The Domain Name System (DNS) is the global hierarchical replicated distributed database system for Internet addressing, mail proxy, and other information. The DNS has been extended to include digital signatures and cryptographic keys as described in [RFC 2535]. Thus the DNS can now be secured and used for secure key distribution.

ドメイン名システム(DNS)は、インターネットアドレス指定、メールプロキシ、およびその他の情報のためのグローバル階層複製分散データベースシステムです。DNSは、[RFC 2535]で説明されているように、デジタル署名と暗号化キーを含むように拡張されています。したがって、DNSを保護し、安全なキー分布に使用できるようになりました。

This document describes how to store RSA keys and and RSA/MD5 based signatures in the DNS. Familiarity with the RSA algorithm is assumed [Schneier]. Implementation of the RSA algorithm in DNS is recommended.

このドキュメントでは、DNSにRSAキーとRSA/MD5ベースの署名を保存する方法について説明します。RSAアルゴリズムに精通していることが想定されています[Schneier]。DNSでのRSAアルゴリズムの実装をお勧めします。

The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119.

このドキュメントの「必須」、「必須」、「必須」、「必要」、「推奨」、および「5月」は、RFC 2119で説明されているように解釈されます。

2. RSA Public KEY Resource Records
2. RSA公開キーリソースレコード

RSA public keys are stored in the DNS as KEY RRs using algorithm number 1 [RFC 2535]. The structure of the algorithm specific portion of the RDATA part of such RRs is as shown below.

RSAパブリックキーは、アルゴリズム番号1 [RFC 2535]を使用して、キー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 currently 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フィールドから決定できます。指数と弾性率では、先頭のゼロオクテットが禁止されています。

3. RSA/MD5 SIG Resource Records
3. RSA/MD5 SIGリソースレコード

The signature portion of the SIG RR RDATA area, when using the RSA/MD5 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/MD5アルゴリズムを使用する場合、SIG RR RDATA領域の署名部分を以下に示します。署名されたデータは、[RFC 2535]で指定されているように決定されます。署名自体に先行するSIG RR RDATAのフィールドについては、[RFC 2535]を参照してください。

hash = MD5 ( data )

Hash = Md5(データ)

     signature = ( 00 | 01 | FF* | 00 | prefix | hash ) ** e (mod n)
        

where MD5 is the message digest algorithm documented in [RFC 1321], "|" 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 MD5 algorithm designator prefix specified in [RFC 2437], that is,

ここで、MD5は[RFC 1321]、「|」で文書化されたメッセージダイジェストアルゴリズムです。「E」は署名者の秘密鍵であり、「n」は署名者の公開鍵の弾性率です。01、FF、および00は、対応する16進価値の固定オクテットです。「プレフィックス」は、[RFC 2437]で指定されたASN.1 BER MD5アルゴリズム指定のプレフィックスです。

hex 3020300c06082a864886f70d020505000410 [NETSEC].

HEX 3020300C06082A864886F70D020505000410 [NETSEC]。

This prefix is included to make it easier to use RSAREF (or similar packages such as EuroRef). The FF octet MUST be repeated the maximum number of times such that the value of the quantity being exponentiated is the same length in octets as the value of n.

このプレフィックスは、RSAREF(またはEuroRefなどの類似パッケージ)を使いやすくするために含まれています。FFオクテットは、指数化される量の値がnの値と同じ長さと同じ長さになるように、最大回数を繰り返す必要があります。

(The above specifications are identical to the corresponding part of Public Key Cryptographic Standard #1 [RFC 2437].)

(上記の仕様は、公開キーの暗号標準#1 [RFC 2437]の対応する部分と同じです。)

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.

最も有意なビットと最も有意なビット(1になる)を含むNのサイズは、512ビット以上、4096ビット以下でなければなりません。nとeは、公開指数が小さいように選択する必要があります。

Leading zero bytes are permitted in the RSA/MD5 algorithm signature.

RSA/MD5アルゴリズムの署名では、先行ゼロバイトが許可されています。

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. This weakness is not significant for DNS security because we seek only authentication, not confidentiality.

3の公開指数は、署名を確認するために必要な努力を最小限に抑えます。パブリック指数として3の使用は機密保持の使用には弱いため、同じデータを3の異なるキーの下で暗号化できた場合、3の指数を持つキーの下で暗号化できる場合、中国の残りの定理[netsec]を使用すると、元のプレーンテキストは簡単に回復できます。。この弱点は、DNSセキュリティにとって重要ではありません。これは、秘密のみではなく認証のみを求めているためです。

4. Performance Considerations
4. パフォーマンスに関する考慮事項

General signature generation speeds are roughly the same for RSA and DSA [RFC 2536]. 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 [RFC 2536]でほぼ同じです。十分な事前計算により、DSAを使用した署名生成はRSAよりも高速です。キー生成は、DSAの方が速いです。ただし、DSAの署名検証は、ドメイン名システム(DNS)データ認証で使用される主要なRRSに推奨されるように、RSAパブリック指数が小さいように選択される場合、DSAで数桁遅くなります。

Current DNS implementations are optimized for small transfers, typically less than 512 bytes including overhead. While larger transfers will perform correctly and work is underway to make larger

現在のDNS実装は、通常、オーバーヘッドを含む512バイト未満で、小さな転送用に最適化されています。より大きな転送が正しく機能し、より大きくなるために作業が進行中です

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内に保存されているキーRRセットのサイズを最小限に抑えるために合理的な努力をすることをお勧めします。安全なゾーンでは、少なくとも1つの認証SIG RRも返されることに注意してください。

5. Security Considerations
5. セキュリティに関する考慮事項

Many of the general security consideration 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.

[RFC 2535]の一般的なセキュリティの考慮事項の多くが適用されます。DNSから取得されたキーは、(1)安全にリゾルバーから安全に取得されたり、ユーザーによって独立して検証されたりしない限り、信頼しないでください。すべての暗号化アルゴリズムと同様に、キーの必要な強さを評価することは不可欠であり、ローカルポリシーに依存します。

For interoperability, the RSA key size is limited to 4096 bits. For particularly critical applications, implementors are encouraged to consider the range of available algorithms and key sizes.

相互運用性のために、RSAキーサイズは4096ビットに制限されています。特に重要なアプリケーションのために、実装者は、利用可能なアルゴリズムとキーサイズの範囲を考慮することをお勧めします。

References

参考文献

[NETSEC] Kaufman, C., Perlman, R. and M. Speciner, "Network Security: PRIVATE Communications in a PUBLIC World", Series in Computer Networking and Distributed Communications, 1995.

[Netsec] Kaufman、C.、Perlman、R。、およびM. Peciner、「ネットワークセキュリティ:公共界のプライベートコミュニケーション」、コンピューターネットワーキングおよび分散通信のシリーズ、1995。

[RFC 2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography Specifications Version 2.0", RFC 2437, October 1998.

[RFC 2437] Kaliski、B。and J. Staddon、「PKCS#1:RSA暗号仕様バージョン2.0」、RFC 2437、1998年10月。

[RFC 1034] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.

[RFC 1034] Mockapetris、P。、「ドメイン名 - 概念と施設」、STD 13、RFC 1034、1987年11月。

[RFC 1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.

[RFC 1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。

[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321 April 1992.

[RFC 1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321 1992年4月。

[RFC 2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

[RFC 2535] Eastlake、D。、「ドメイン名システムセキュリティ拡張機能」、RFC 2535、1999年3月。

[RFC 2536] EastLake, D., "DSA KEYs and SIGs in the Domain Name System (DNS)", RFC 2536, March 1999.

[RFC 2536] Eastlake、D。、「DSA Keys and Sigs in the Domain Name System(DNS)」、RFC 2536、1999年3月。

[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、「適用された暗号化第2版:プロトコル、アルゴリズム、およびCのソースコード」、1996年、John Wiley and Sons、ISBN 0-471-11709-9。

Author's Address

著者の連絡先

Donald E. Eastlake 3rd IBM 65 Shindegan Hill Road, RR #1 Carmel, NY 10512

ドナルドE.イーストレイク3rd IBM 65 Shindegan Hill Road、RR#1カーメル、ニューヨーク10512

   Phone:   +1-914-276-2668(h)
            +1-914-784-7913(w)
   Fax:     +1-914-784-3833(w)
   EMail:   dee3@us.ibm.com
        

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (1999). All Rights Reserved.

Copyright(c)The Internet Society(1999)。全著作権所有。

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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。