RFC 5933 - Use of GOST Signature Algorithms in DNSKEY and RRSIG Resource Records for DNSSEC 日本語訳

URL : https://tools.ietf.org/html/rfc5933
タイトル : RFC 5933 - DNSSECのためのDNSKEYとRRSIGリソースレコードでGOST署名アルゴリズムの使用
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                  V. Dolmatov, Ed.
Request for Comments: 5933                                   A. Chuprina
Category: Standards Track                                     I. Ustinov
ISSN: 2070-1721                                           Cryptocom Ltd.
                                                               July 2010

               Use of GOST Signature Algorithms in DNSKEY
                 and RRSIG Resource Records for DNSSEC

Abstract

抽象

This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2001 and GOST R 34.11-94 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC).

この文書では、ドメインネームシステムセキュリティ拡張（DNSSEC）で使用するために、DNSKEY、RRSIG、およびDSリソースレコードのGOST R 34.10から2001とGOST R 34.11から94のアルゴリズムを使用してデジタル署名とハッシュ関数を生成する方法について説明します。

Status of This Memo

このメモのステータス

This is an Internet Standards Track document.

これは、インターネット標準化過程文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5933.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5933で取得することができます。

著作権表示

著作権（C）2010 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 Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
     1.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  DNSKEY Resource Records . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Using a Public Key with Existing Cryptographic
           Libraries . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  GOST DNSKEY RR Example  . . . . . . . . . . . . . . . . . . 4
   3.  RRSIG Resource Records  . . . . . . . . . . . . . . . . . . . . 4
     3.1.  RRSIG RR Example  . . . . . . . . . . . . . . . . . . . . . 5
   4.  DS Resource Records . . . . . . . . . . . . . . . . . . . . . . 5
     4.1.  DS RR Example . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 6
     5.1.  Key Sizes . . . . . . . . . . . . . . . . . . . . . . . . . 6
     5.2.  Signature Sizes . . . . . . . . . . . . . . . . . . . . . . 6
     5.3.  Digest Sizes  . . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Implementation Considerations . . . . . . . . . . . . . . . . . 6
     6.1.  Support for GOST Signatures . . . . . . . . . . . . . . . . 6
     6.2.  Support for NSEC3 Denial of Existence . . . . . . . . . . . 6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   9.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 7
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction

1. はじめに

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. RFC 4033 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] describe these DNS Security Extensions, called DNSSEC.

ドメインネームシステム（DNS）は、インターネットネーミングのためのグローバルな階層型分散データベースです。 DNSは、そのデータの真正性と完全性を検証するための暗号鍵とデジタル署名を使用するように拡張されました。 RFC 4033 [RFC4033]、RFC 4034 [RFC4034]、およびRFC 4035 [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 signature and hash algorithms GOST R 34.10-2001 ([GOST3410], [RFC5832]) and GOST R 34.11-94 ([GOST3411], [RFC5831]), and specifies how to store DNSKEY data and how to produce RRSIG resource records with these algorithms.

RFC 4034は、DNSKEYとRRSIGリソースレコードを保存する方法について説明し、使用する暗号化アルゴリズムのリストを指定します。この文書は、署名およびハッシュアルゴリズムGOST R 34.10から2001（[GOST3410]、[RFC5832]）とGOST R 34.11から94（[GOST3411]、[RFC5831]）とそのリストを拡張し、DNSKEYデータを保存する方法を指定し、どのようにこれらのアルゴリズムでRRSIGリソースレコードを生成します。

Familiarity with DNSSEC and with GOST signature and hash algorithms is assumed in this document.

DNSSECとおよびGOST署名及びハッシュアルゴリズムに精通は本書で想定しています。

The term "GOST" is not officially defined, but is usually used to refer to the collection of the Russian cryptographic algorithms GOST R 34.10-2001 [RFC5832], GOST R 34.11-94 [RFC5831], and

用語「GOSTは」正式に定義されていないが、通常はロシア暗号化アルゴリズムGOST R 34.10から2001 [RFC5832]、GOST R 34.11から94 [RFC5831]のコレクションを参照するために使用され、

GOST 28147-89 [RFC5830]. Since GOST 28147-89 is not used in DNSSEC, "GOST" will only refer to GOST R 34.10-2001 and GOST R 34.11-94 in this document.

GOST 28147から89 [RFC5830]。 GOST 28147から89をDNSSECで使用されていないので、「GOSTは、」のみ、この文書でGOST R 34.10から2001とGOST R 34.11から94を参照します。

1.1. Terminology

1.1. 用語

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]に記載されているように解釈されます。

2. DNSKEY Resource Records

2. DNSKEYリソースレコード

The format of the DNSKEY RR can be found in RFC 4034 [RFC4034].

DNSKEY RRのフォーマットは、RFC 4034 [RFC4034]に見出すことができます。

GOST R 34.10-2001 public keys are stored with the algorithm number 12.

GOST R 34.10から2001の公開鍵はアルゴリズム番号12で記憶されています。

The wire format of the public key is compatible with RFC 4491 [RFC4491]:

公開鍵のワイヤフォーマットは、RFC 4491 [RFC4491]と互換性があります。

According to [GOST3410] and [RFC5832], a public key is a point on the elliptic curve Q = (x,y).

【GOST3410]と[RFC5832]によれば、公開鍵は、楕円曲線Q =（X、Y）上の点です。

The wire representation of a public key MUST contain 64 octets, where the first 32 octets contain the little-endian representation of x and the second 32 octets contain the little-endian representation of y.

公開鍵のワイヤ表現は、最初の32個のオクテットは、xのリトルエンディアン表現を含み、第32オクテットは、Yのリトルエンディアン表現を含む64個のオクテットを含まなければなりません。

Corresponding public key parameters are those identified by id-GostR3410-2001-CryptoPro-A-ParamSet (1.2.643.2.2.35.1) [RFC4357], and the digest parameters are those identified by id-GostR3411-94-CryptoProParamSet (1.2.643.2.2.30.1) [RFC4357].

対応する公開鍵パラメータは、それらのID-GostR3410-2001-CryptoPro-A-ParamSet（1.2.643.2.2.35.1）[RFC4357]によって識別され、ダイジェストパラメータは1.2（ID-GostR3411-94-CryptoProParamSetによって同定されたものです。さ643.2.2.30.1）[RFC4357]。

2.1. Using a Public Key with Existing Cryptographic Libraries

2.1. 既存の暗号化ライブラリと公開鍵を使用して

At the time of this writing, existing GOST-aware cryptographic libraries are capable of reading GOST public keys via a generic X509 API if the key is encoded according to RFC 4491 [RFC4491], Section 2.3.2.

この記事の執筆時点では、既存のGOST-意識暗号化ライブラリは鍵がRFC 4491 [RFC4491]、セクション2.3.2に従って符号化されている場合、一般的なX509 APIを介してGOST公開鍵を読み取ることができます。

To make this encoding from the wire format of a GOST public key with the parameters used in this document, prepend the 64 octets of key data with the following 37-byte sequence:

本文書で使用されるパラメータとGOST公開鍵のワイヤフォーマットからこの符号化を行うために、次の37バイトのシーケンスと鍵データの64個のオクテットを付加：

0x30 0x63 0x30 0x1c 0x06 0x06 0x2a 0x85 0x03 0x02 0x02 0x13 0x30 0x12 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x23 0x01 0x06 0x07 0x2a 0x85 0x03 0x02 0x02 0x1e 0x01 0x03 0x43 0x00 0x04 0x40

0x30からは0x63 0x30から0x06で0x1cに0x06で0x2a 0x85 0x03の0x02の0x02の0x13に0x30から0x12を0x06で0x07の0x2a 0x85 0x03の0x02の0x02の0x23が0x01 0x06で0x07の0x2a 0x85 0x03の0x02の0x02の0x1eが表示が0x01 0x03の0x43この0x00から0x04が0x40の

2.2. GOST DNSKEY RR Example

2.2. GOST DNSKEY RRの例

Given a private key with the following value (the value of the GostAsn1 field is split here into two lines to simplify reading; in the private key file, it must be in one line):

次の値を持つ秘密鍵（GostAsn1フィールドの値を読み取りを簡素化するために2行に分割され、ここで、秘密鍵ファイルで、それは1行でなければなりません）を考えます：

Private-key-format: v1.2 Algorithm: 12 (ECC-GOST) GostAsn1: MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg/9M iXtXKg9FDXDN/R9CmVhJDyuzRAIgh4tPwCu4NHIs=

秘密鍵形式：V1.2アルゴリズム：12（ECC-GOST）GostAsn1：MEUCAQAwHAYGKoUDAgITMBIGByqFAwICIwEGByqFAwICHgEEIgQg / 9M iXtXKg9FDXDN / R9CmVhJDyuzRAIgh4tPwCu4NHIs =

The following DNSKEY RR stores a DNS zone key for example.net:

以下のDNSKEY RRはexample.netのDNSゾーンのキーを格納します。

example.net. 86400 IN DNSKEY 256 3 12 ( aRS/DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV+t/6 w4X1gpNrZiC01g== ) ; key id = 59732

example.net。 DNSKEY 256 3 12 IN 86400（ARS / DcPWGQj2wVJydT8EcAVoC0kXn5pDVm2I MvDDPXeD32dsSKcmq8KNVzigjL4OXZTV + T / 6 w4X1gpNrZiC01g ==）。キーID = 59732

3. RRSIG Resource Records

3. RRSIGレコードリソース

The value of the signature field in the RRSIG RR follows RFC 4490 [RFC4490] and is calculated as follows. The values for the RDATA fields that precede the signature data are specified in RFC 4034 [RFC4034].

RRSIG RRでの署名フィールドの値は、RFC 4490 [RFC4490]を、以下、次のように計算されます。署名データに先行RDATAフィールドの値は、RFC 4034 [RFC4034]で指定されています。

hash = GOSTR3411(data)

ハッシュ= GOSTR3411（データ）

where "data" is the wire format data of the resource record set that is signed, as specified in RFC 4034 [RFC4034].

「データ」は、RFC 4034 [RFC4034]で指定されるように、署名されているリソースレコードセットのワイヤー形式のデータです。

The hash MUST be calculated with GOST R 34.11-94 parameters identified by id-GostR3411-94-CryptoProParamSet [RFC4357].

ハッシュは、GOST R ID-GostR3411-94-CryptoProParamSet [RFC4357]によって識別34.11から94個のパラメータを用いて計算しなければなりません。

The signature is calculated from the hash according to the GOST R 34.10-2001 standard, and its wire format is compatible with RFC 4490 [RFC4490].

署名は、GOST R 34.10から2001標準に従ってハッシュから計算し、そのワイヤフォーマットは、RFC 4490 [RFC4490]との互換性です。

Quoting RFC 4490:

RFC 4490を引用：

"The signature algorithm GOST R 34.10-2001 generates a digital signature in the form of two 256-bit numbers, r and s. Its octet string representation consists of 64 octets, where the first 32 octets contain the big-endian representation of s and the second 32 octets contain the big-endian representation of r".

「署名アルゴリズムGOSTのR 34.10から2001は、2つの256ビットの番号、rおよびsの形でデジタル署名を生成する。そのオクテットストリング表現が最初の32個のオクテットは、Sのビッグエンディアン表現を含み、64個のオクテットで構成さ次の32個のオクテットは「Rのビッグエンディアン表現を含んでいます。

3.1. RRSIG RR Example

3.1. RRSIG RRの例

With the private key from Section 2.2, sign the following RRSet, consisting of one A record:

2.2から秘密鍵を使用すると、一つのレコードからなる、資源レコード集合以下の署名：

www.example.net. 3600 IN A 192.0.2.1

www.example.net。 192.0.2.1 3600

Setting the inception date to 2000-01-01 00:00:00 UTC and the expiration date to 2030-01-01 00:00:00 UTC, the following signature RR will be valid:

2000-01-01 00:00:00に開始日と2030年1月1日00:00:00に有効期限を設定すると、次の署名RRが有効となります。

www.example.net. 3600 IN RRSIG A 12 3 3600 20300101000000 ( 20000101000000 59732 example.net. 7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp kNPkUnS8iIns0Kv4APT+D9ibmHhGri6Sfbyy zi67+wBbbW/jrA== )

Wwv.akshmpleknet。 3600 RRSIG IN A 12 3 3600 20300101000000（20000101000000 59732 Exampleknet。7vzzz6iLOmvtjs5FjVjSHT8XnRKFY15ki6Kp kNPkUnS8iIns0Kv4APT + D9ibmHhGri6Sfbyy zi67 + wBbbW / JRA ==）

Note: The ECC-GOST signature algorithm uses random data, so the actual computed signature value will differ between signature calculations.

注意：ECC-GOST署名アルゴリズムは、ランダムなデータを使用するため、実際の計算された署名値は、署名の計算の間で異なるであろう。

4. DS Resource Records

4. DSリソースレコード

The GOST R 34.11-94 digest algorithm is denoted in DS RRs by the digest type 3. The wire format of a digest value is compatible with RFC 4490 [RFC4490], that is, the digest is in little-endian representation.

GOST R 34.11から94は、ダイジェストアルゴリズムつまり、ダイジェストタイプ3.ダイジェスト値のワイヤフォーマットは、RFC 4490と互換性がある[RFC4490]でDSのRRに示され、ダイジェストは、リトルエンディアン表現です。

The digest MUST always be calculated with GOST R 34.11-94 parameters identified by id-GostR3411-94-CryptoProParamSet [RFC4357].

ダイジェストは、常にID-GostR3411-94-CryptoProParamSet [RFC4357]によって識別GOST R 34.11から94個のパラメータを用いて計算しなければなりません。

4.1. DS RR Example

4.1. DS RRの例

For Key Signing Key (KSK):

キー署名キー（KSK）の場合：

example.net. 86400 DNSKEY 257 3 12 ( LMgXRHzSbIJGn6i16K+sDjaDf/k1o9DbxScO gEYqYS/rlh2Mf+BRAY3QHPbwoPh2fkDKBroF SRGR7ZYcx+YIQw== ) ; key id = 40692

example.net。 86400 DNSKEY 257 3 12（LMgXRHzSbIJGn6i16K + sDjaDf / k1o9DbxScO gEYqYS / rlh2Mf + BRAY3QHPbwoPh2fkDKBroF SRGR7ZYcx + YIQw ==）。キーID = 40692

The DS RR will be

DS RRは次のようになります

example.net. 3600 IN DS 40692 12 3 ( 22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B 2071398F )

example.net。 DS 40692 12 3（22261A8B0E0D799183E35E24E2AD6BB58533CBA7E3B14D659E9CA09B 2071398F）3600

5. Deployment Considerations

5.展開の考慮事項

5.1. Key Sizes

5.1. 鍵のサイズ

According to RFC 4357 [RFC4357], the key size of GOST public keys MUST be 512 bits.

RFC 4357 [RFC4357]によれば、GOST公開鍵の鍵サイズは512ビットでなければなりません。

5.2. Signature Sizes

5.2. 署名のサイズ

According to the GOST R 34.10-2001 digital signature algorithm specification ([GOST3410], [RFC5832]), the size of a GOST signature is 512 bits.

GOST R 34.10から2001デジタル署名アルゴリズムの仕様（[GOST3410]、[RFC5832]）によれば、GOST署名のサイズは512ビットです。

5.3. Digest Sizes

5.3. ダイジェストサイズ

According to GOST R 34.11-94 ([GOST3411], [RFC5831]), the size of a GOST digest is 256 bits.

GOST R 34.11から94（[GOST3411]、[RFC5831]）によれば、GOSTダイジェストのサイズは256ビットです。

6. Implementation Considerations

6.実装に関する考慮事項

6.1. Support for GOST Signatures

6.1. GOST署名のサポート

DNSSEC-aware implementations MAY be able to support RRSIG and DNSKEY resource records created with the GOST algorithms as defined in this document.

DNSSEC対応の実装では、この文書で定義されているGOSTアルゴリズムを使用して作成RRSIGとDNSKEYリソースレコードをサポートすることができるかもしれません。

6.2. Support for NSEC3 Denial of Existence

6.2. 存在のNSEC3拒否のサポート

Any DNSSEC-GOST implementation MUST support both NSEC [RFC4035] and NSEC3 [RFC5155].

任意DNSSEC-GOST実装はNSEC [RFC4035]とNSEC3 [RFC5155]の両方をサポートしなければなりません。

7. Security Considerations

7.セキュリティの考慮事項

Currently, the cryptographic resistance of the GOST R 34.10-2001 digital signature algorithm is estimated as 2**128 operations of multiple elliptic curve point computations on prime modulus of order 2**256.

現在、GOST Rの暗号抵抗34.10から2001デジタル署名アルゴリズムは、注文2 ** 256のプライムモジュラスの複数の楕円曲線点計算の2つの** 128の操作として推定されます。

Currently, the cryptographic resistance of the GOST R 34.11-94 hash algorithm is estimated as 2**128 operations of computations of a step hash function. (There is a known method to reduce this estimate to 2**105 operations, but it demands padding the colliding message with 1024 random bit blocks each of 256-bit length; thus, it cannot be used in any practical implementation).

現在、GOST R 34.11から94のハッシュアルゴリズムの暗号抵抗はステップハッシュ関数の計算の2つの** 128の操作として推定されます。（そこ2つの** 105の操作にこの推定値を低減することが知られている方法であるが、それは、1024のランダムビットブロック256ビット長の各衝突メッセージをパディング要求するので、これは、任意の実用的な実装では使用できません）。

8. IANA Considerations

8. IANAの考慮事項

This document updates the IANA registry "DNS Security Algorithm Numbers" [RFC4034]. The following entries have been added to the registry:

このドキュメントは、IANAレジストリ「DNSセキュリティアルゴリズム番号」[RFC4034]を更新します。次のエントリがレジストリに追加されました。

Zone Trans. Value Algorithm Mnemonic Signing Sec. References Status 12 GOST R 34.10-2001 ECC-GOST Y * RFC 5933 OPTIONAL

ゾーントランス。バリューアルゴリズムニーモニックは、SECに署名します。参考文献ステータス12 GOST R 34.10から2001 ECC-GOST Y * RFC 5933オプション

This document updates the RFC 4034 Digest Types assignment ([RFC4034], Section A.2) by adding the value and status for the GOST R 34.11-94 algorithm:

この文書は、GOST R 34.11から94アルゴリズムの値とステータスを追加することによって、RFC 4034ダイジェストタイプの割り当て（[RFC4034]、セクションA.2）を更新します。

Value Algorithm Status 3 GOST R 34.11-94 OPTIONAL

バリューアルゴリズムステータス3 GOST Rオプション34.11から94

9. Acknowledgments

9.謝辞

This document is a minor extension to RFC 4034 [RFC4034]. Also, we tried to follow the documents RFC 3110 [RFC3110], RFC 4509 [RFC4509], and RFC 4357 [RFC4357] for consistency. The authors of and contributors to these documents are gratefully acknowledged for their hard work.

この文書は、RFC 4034 [RFC4034]にマイナーな拡張機能です。また、我々は一貫性を保つために、文書RFC 3110 [RFC3110]、RFC 4509 [RFC4509]、およびRFC 4357 [RFC4357]を辿ることを試みました。これらの文書の作者と貢献は感謝して彼らのハードワークのために認められています。

The following people provided additional feedback, text, and valuable assistance: Dmitry Burkov, Jaap Akkerhuis, Olafur Gundmundsson, Jelte Jansen, and Wouter Wijngaards.

ドミットリー・バーコブ、ヤープAkkerhuis、オラフルGundmundsson、Jelteヤンセン、とはWouter Wijngaards：次の人は追加のフィードバック、テキスト、および貴重な支援を提供します。

10. References

10.参考文献

10.1. Normative References

10.1. 引用規格

[GOST3410] "Information technology. Cryptographic data security. Signature and verification processes of [electronic] digital signature.", GOST R 34.10-2001, Gosudarstvennyi Standard of Russian Federation, Government Committee of Russia for Standards, 2001. (In Russian).

[GOST3410]「情報技術。[電子]デジタル署名の暗号データセキュリティ。署名と検証のプロセス。」、GOST R 34.10から2001、ロシア連邦、（ロシア語で）規格のためのロシアの政府委員会、2001年のGosudarstvennyi標準。

[GOST3411] "Information technology. Cryptographic data security. Hashing function.", GOST R 34.11-94, Gosudarstvennyi Standard of Russian Federation, Government Committee of Russia for Standards, 1994. (In Russian).

[GOST3411]「情報技術。暗号化データのセキュリティ。ハッシュ関数。」、GOST R 34.11から94、ロシア連邦、（ロシア語で）規格のためのロシアの政府委員会、1994年のGosudarstvennyi標準。

[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 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001.

[RFC3110]イーストレーク3日、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月。

[RFC4357] Popov, V., Kurepkin, I., and S. Leontiev, "Additional Cryptographic Algorithms for Use with GOST 28147-89, GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms", RFC 4357, January 2006.

[RFC4357]ポポフ、V.、Kurepkin、I.、およびS. Leontiev、 "その他の暗号アルゴリズムGOST 28147から89、GOST R 34.10から94、GOST R 34.10から2001、およびGOST Rとの使用のために34.11から94のアルゴリズム" 、RFC 4357、2006年1月。

[RFC4490] Leontiev, S., Ed. and G. Chudov, Ed., "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)", RFC 4490, May 2006.

[RFC4490] Leontiev、S.、エド。そして、G. Chudov、エド。、RFC 4490、2006年5月 "暗号メッセージ構文（CMS）とGOST 28147から89、GOST R 34.11から94、GOST R 34.10から94、およびGOST R 34.10から2001アルゴリズムを使用します"。

[RFC4491] Leontiev, S., Ed. and D. Shefanovski, Ed., "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 4491, May 2006.

[RFC4491] Leontiev、S.、エド。そして、D. Shefanovski、エド。、RFC 4491、2006年5月 "GOST R 34.10から94、GOST R 34.10から2001、およびGOST RインターネットX.509公開鍵基盤証明書とCRLプロフィールと34.11から94のアルゴリズムを使用します" 。

[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月。

10.2. Informative References

10.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の使用"。

[RFC5830] Dolmatov, V., Ed., "GOST 28147-89: Encryption, Decryption, and Message Authentication Code (MAC) Algorithms", RFC 5830, March 2010.

[RFC5830] Dolmatov、V.、エド、 "GOST 28147から89：暗号化、復号化、およびメッセージ認証コード（MAC）アルゴリズム"。、RFC 5830、2010年3月。

[RFC5831] Dolmatov, V., Ed., "GOST R 34.11-94: Hash Function Algorithm", RFC 5831, March 2010.

[RFC5831] Dolmatov、V.、エド、 "GOST R 34.11から94：ハッシュ関数アルゴリズム"。、RFC 5831、2010年3月。

[RFC5832] Dolmatov, V., Ed., "GOST R 34.10-2001: Digital Signature Algorithm", RFC 5832, March 2010.

[RFC5832] Dolmatov、V.、エド、 "GOST R 34.10から2001：デジタル署名アルゴリズム"。、RFC 5832、2010年3月。

Authors' Addresses

著者のアドレス

Vasily Dolmatov (editor) Cryptocom Ltd. 14/2, Kedrova St. Moscow, 117218 Russian Federation

ワシーリーDolmatov（エディタ）Cryptocom株式会社14/2、Kedrova聖モスクワ、117218ロシア連邦

Phone: +7 499 124 6226 EMail: dol@cryptocom.ru

電話番号：+7 499 124 6226 Eメール：dol@cryptocom.ru

Artem Chuprina Cryptocom Ltd. 14/2, Kedrova St. Moscow, 117218 Russian Federation

アルテムChuprina Cryptocom株式会社14/2、Kedrova聖モスクワ、117218ロシア連邦

Phone: +7 499 124 6226 EMail: ran@cryptocom.ru

電話番号：+7 499 124 6226 Eメール：ran@cryptocom.ru

Igor Ustinov Cryptocom Ltd. 14/2, Kedrova St. Moscow, 117218 Russian Federation

イゴール・ユスティノフCryptocom株式会社14/2、Kedrova聖モスクワ、117218ロシア連邦

Phone: +7 499 124 6226 EMail: igus@cryptocom.ru

電話番号：+7 499 124 6226 Eメール：igus@cryptocom.ru