RFC2631 日本語訳
2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999. (Format: TXT=25932 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rescorla Request for Comments: 2631 RTFM Inc. Category: Standards Track June 1999
コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 2631年のRTFM株式会社カテゴリ: 標準化過程1999年6月
Diffie-Hellman Key Agreement Method
ディフィー-ヘルマンの主要な協定方法
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This document standardizes one particular Diffie-Hellman variant, based on the ANSI X9.42 draft, developed by the ANSI X9F1 working group. Diffie-Hellman is a key agreement algorithm used by two parties to agree on a shared secret. An algorithm for converting the shared secret into an arbitrary amount of keying material is provided. The resulting keying material is used as a symmetric encryption key. The Diffie-Hellman variant described requires the recipient to have a certificate, but the originator may have a static key pair (with the public key placed in a certificate) or an ephemeral key pair.
このドキュメントはANSI X9F1ワーキンググループによって開発されたANSI X9.42草稿に基づく1つの特定のディフィー-ヘルマン異形を標準化します。 ディフィー-ヘルマンは共有秘密キーに同意するのに2回のパーティーによって使用された主要な協定アルゴリズムです。 材料を任意の量合わせるのに共有秘密キーを変換するためのアルゴリズムを提供します。 材料を合わせる結果になることは左右対称の暗号化キーとして使用されます。 説明されたディフィー-ヘルマン異形は、受取人には証明書があるのを必要としますが、創始者では、静的な主要な組(公開鍵が証明書に置かれている)かはかない主要な組があるかもしれません。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 2 2. Overview Of Method . . . . . . . . . . . . . . . . . . . . 2 2.1. Key Agreement . . . . . . . . . . . . . . . . . . . . . . 2 2.1.1. Generation of ZZ . . . . . . . . . . . . . . . . . . . 3 2.1.2. Generation of Keying Material . . . . . . . . . . . . . 3 2.1.3. KEK Computation . . . . . . . . . . . . . . . . . . . . 4 2.1.4. Keylengths for common algorithms . . . . . . . . . . . 5 2.1.5. Public Key Validation . . . . . . . . . . . . . . . . . 5 2.1.6. Example 1 . . . . . . . . . . . . . . . . . . . . . . . 5 2.1.7. Example 2 . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. Key and Parameter Requirements . . . . . . . . . . . . . 7 2.2.1. Group Parameter Generation . . . . . . . . . . . . . . 7 2.2.1.1. Generation of p, q . . . . . . . . . . . . . . . . . 8
1. 序論. . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件用語. . . . . . . . . . . . . . . . 2 2 方法. . . . . . . . . . . . . . . . . . . . 2 2.1の概観。 主要な協定. . . . . . . . . . . . . . . . . . . . . . 2 2.1.1。 ZZ. . . . . . . . . . . . . . . . . . . 3 2.1.2人の世代。 合わせることの材料. . . . . . . . . . . . . 3 2.1.3人の世代。 KEK計算. . . . . . . . . . . . . . . . . . . . 4 2.1.4。 一般的なアルゴリズム. . . . . . . . . . . 5 2.1.5のためのKeylengths。 公開鍵合法化. . . . . . . . . . . . . . . . . 5 2.1.6。 例、1 .52.1 .7。 例2の.62.2。 キーとパラメタ要件. . . . . . . . . . . . . 7 2.2.1。 パラメタ世代. . . . . . . . . . . . . . 7 2.2.1.1を分類してください。 pの世代、q.8
Rescorla Standards Track [Page 1] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[1ページ]RFC2631ディフィー-ヘルマン
2.2.1.2. Generation of g . . . . . . . . . . . . . . . . . . . 9 2.2.2. Group Parameter Validation . . . . . . . . . . . . . . 9 2.3. Ephemeral-Static Mode . . . . . . . . . . . . . . . . . . 10 2.4. Static-Static Mode . . . . . . . . . . . . . . . . . . . 10 2.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 2.4. References . . . . . . . . . . . . . . . . . . . . . . . 11 Security Considerations . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
2.2.1.2. g. . . . . . . . . . . . . . . . . . . 9 2.2.2人の世代。 パラメタ合法化. . . . . . . . . . . . . . 9 2.3を分類してください。 はかなく静的なモード. . . . . . . . . . . . . . . . . . 10 2.4。 静的に静的なモード. . . . . . . . . . . . . . . . . . . 10 2.4。 承認. . . . . . . . . . . . . . . . . . . . 10 2.4。 参照. . . . . . . . . . . . . . . . . . . . . . . 11セキュリティ問題. . . . . . . . . . . . . . . . . . . 12作者のアドレスの.12の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 13
1. Introduction
1. 序論
In [DH76] Diffie and Hellman describe a means for two parties to agree upon a shared secret in such a way that the secret will be unavailable to eavesdroppers. This secret may then be converted into cryptographic keying material for other (symmetric) algorithms. A large number of minor variants of this process exist. This document describes one such variant, based on the ANSI X9.42 specification.
[DH76]では、ディフィーとヘルマンは2回のパーティーが秘密が立ち聞きする者にとって入手できなくなるような方法で共有秘密キーに同意する手段を説明します。 次に、この秘密は他の(左右対称)のアルゴリズムのための暗号の合わせることの材料に変換されるかもしれません。この過程の多くの小さい方の異形が存在しています。 このドキュメントはANSI X9.42仕様に基づいてそのような異形の1つについて説明します。
1.1. Requirements Terminology
1.1. 要件用語
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and "MAY" that appear in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。
2. Overview Of Method
2. 方法の概観
Diffie-Hellman key agreement requires that both the sender and recipient of a message have key pairs. By combining one's private key and the other party's public key, both parties can compute the same shared secret number. This number can then be converted into cryptographic keying material. That keying material is typically used as a key-encryption key (KEK) to encrypt (wrap) a content- encryption key (CEK) which is in turn used to encrypt the message data.
ディフィー-ヘルマンの主要な協定は、送付者とメッセージの受取人の両方には主要な組があるのを必要とします。 人の秘密鍵と相手の公開鍵を結合することによって、双方は同じ共有秘密キー番号を計算できます。 そして、暗号の合わせることの材料にこの数を変換できます。 その合わせることの材料は、メッセージデータをコード化するのに順番に使用される内容暗号化キー(CEK)をコード化すること(包装する)に主要な暗号化キー(KEK)として通常使用されます。
2.1. Key Agreement
2.1. 主要な協定
The first stage of the key agreement process is to compute a shared secret number, called ZZ. When the same originator and recipient public/private key pairs are used, the same ZZ value will result. The ZZ value is then converted into a shared symmetric cryptographic key. When the originator employs a static private/public key pair, the introduction of a public random value ensures that the resulting symmetric key will be different for each key agreement.
ZZは、主要な協定の過程の第一段階が共有秘密キー番号を計算することであると呼びました。 同じ創始者と受取人公衆/秘密鍵組が使用されているとき、同じZZ値は結果として生じるでしょう。 そして、ZZ値は共有された左右対称の暗号化キーに変換されます。 創始者が静的な私設の/公開鍵組を雇うとき、公共の無作為の価値の導入は、結果として起こる対称鍵がそれぞれの主要な協定において異なるようになるのを確実にします。
Rescorla Standards Track [Page 2] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[2ページ]RFC2631ディフィー-ヘルマン
2.1.1. Generation of ZZ
2.1.1. ZZの世代
X9.42 defines that the shared secret ZZ is generated as follows:
X9.42はそれを定義します。共有秘密キーZZは以下の通り発生します:
ZZ = g ^ (xb * xa) mod p
ZZはg^(xb*xa)モッズpと等しいです。
Note that the individual parties actually perform the computations:
個々のパーティーが実際に計算を実行することに注意してください:
ZZ = (yb ^ xa) mod p = (ya ^ xb) mod p
ZZがモッズp=と等しい、(Yb^xa)(あなた、^xb) モッズp
where ^ denotes exponentiation
^が羃法を指示するところ
ya is party a's public key; ya = g ^ xa mod p
yb is party b's public key; yb = g ^ xb mod p
xa is party a's private key
xb is party b's private key
p is a large prime
q is a large prime
g = h^{(p-1)/q} mod p, where
h is any integer with 1 < h < p-1 such that h{(p-1)/q} mod p > 1
(g has order q mod p; i.e. g^q mod p = 1 if g!=1)
j a large integer such that p=qj + 1
(See Section 2.2 for criteria for keys and parameters)
あなたはパーティーaの公開鍵です。 g^xaモッズpあなた=Ybはパーティーbの公開鍵です。 Yb..モッズ..パーティー..秘密鍵..パーティー..秘密鍵..大きい..主要..大きい..主要..モッズ..整数..モッズ風..持つ..オーダー..モッズ..すなわち..モッズ..等しい..大きい..整数(キーとパラメタの評価基準に関してセクション2.2を見ます)
In [CMS], the recipient's key is identified by the CMS RecipientIdentifier, which points to the recipient's certificate. The sender's public key is identified using the OriginatorIdentifierOrKey field, either by reference to the sender's certificate or by inline inclusion of a public key.
[CMS]では、受取人のキーはCMS RecipientIdentifierによって特定されます。(CMS RecipientIdentifierは受取人の証明書を示します)。 送付者の公開鍵は、送付者の証明書の参照か公開鍵のインライン包含でOriginatorIdentifierOrKey分野を使用することで特定されます。
2.1.2. Generation of Keying Material
2.1.2. 材料を合わせる世代
X9.42 provides an algorithm for generating an essentially arbitrary amount of keying material from ZZ. Our algorithm is derived from that algorithm by mandating some optional fields and omitting others.
X9.42はZZから本質的には任意の量の合わせることの材料を発生させるためのアルゴリズムを提供します。 そのアルゴリズムからいくつかの任意の分野を強制して、他のものを省略することによって、私たちのアルゴリズムを得ます。
KM = H ( ZZ || OtherInfo)
kmはHと等しいです。(ZZ| | OtherInfo)
H is the message digest function SHA-1 [FIPS-180] ZZ is the shared secret value computed in Section 2.1.1. Leading zeros MUST be preserved, so that ZZ occupies as many octets as p. For instance, if p is 1024 bits, ZZ should be 128 bytes long. OtherInfo is the DER encoding of the following structure:
Hによるメッセージダイジェスト関数SHA-1[FIPS-180]ZZがセクション2.1.1で計算された共有秘密キー値であるということです。 先行ゼロを保存しなければならないので、ZZはpと同じくらい多くの八重奏を占領します。 例えば、pが1024ビットであるなら、ZZは128バイト長であるべきです。 OtherInfoは以下の構造のDERコード化です:
OtherInfo ::= SEQUENCE {
keyInfo KeySpecificInfo,
partyAInfo [0] OCTET STRING OPTIONAL,
suppPubInfo [2] OCTET STRING
OtherInfo:、:= 系列、keyInfo KeySpecificInfo、任意のpartyAInfo[0]八重奏ストリングsuppPubInfo[2]八重奏ストリング
Rescorla Standards Track [Page 3] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[3ページ]RFC2631ディフィー-ヘルマン
}
}
KeySpecificInfo ::= SEQUENCE {
algorithm OBJECT IDENTIFIER,
counter OCTET STRING SIZE (4..4) }
KeySpecificInfo:、:= 系列アルゴリズムOBJECT IDENTIFIER、カウンタOCTET STRING SIZE(4 .4)
Note that these ASN.1 definitions use EXPLICIT tagging. (In ASN.1, EXPLICIT tagging is implicit unless IMPLICIT is explicitly specified.)
これらのASN.1定義がEXPLICITタグ付けを使用することに注意してください。 (ASN.1では、IMPLICITが明らかに指定されない場合、EXPLICITタグ付けは暗に示されています。)
algorithm is the ASN.1 algorithm OID of the CEK wrapping algorithm
with which this KEK will be used. Note that this is NOT an
AlgorithmIdentifier, but simply the OBJECT IDENTIFIER. No
parameters are used.
アルゴリズムはこのKEKが使用されるCEKラッピングアルゴリズムのASN.1アルゴリズムOIDです。 これがAlgorithmIdentifierではなく、単にOBJECT IDENTIFIERであることに注意してください。 どんなパラメタも使用されていません。
counter is a 32 bit number, represented in network byte order. Its
initial value is 1 for any ZZ, i.e. the byte sequence 00 00 00 01
(hex), and it is incremented by one every time the above key
generation function is run for a given KEK.
カウンタはネットワークバイトオーダーで表された32ビットの数です。 初期の値はどんなZZのための1です、すなわち、バイト列00 00 00 01(魔法をかけます)、そして、上のキー生成機能が与えられたKEKのために走るときはいつも、それは1つ増加されます。
partyAInfo is a random string provided by the sender. In CMS, it is
provided as a parameter in the UserKeyingMaterial field (encoded as
an OCTET STRING). If provided, partyAInfo MUST contain 512 bits.
partyAInfoは送付者によって提供された無作為のストリングです。 CMSでは、パラメタとしてUserKeyingMaterial分野(OCTET STRINGとして、コード化される)にそれを提供します。 提供するなら、partyAInfoは512ビットを含まなければなりません。
suppPubInfo is the length of the generated KEK, in bits, represented
as a 32 bit number in network byte order. E.g. for 3DES it would be
the byte sequence 00 00 00 C0.
suppPubInfoはネットワークバイトオーダーにおける32ビットの数として表されたビットの発生しているKEKの長さです。 例えば、3DESに関しては、それはバイト列00 00 00C0でしょう。
To generate a KEK, one generates one or more KM blocks (incrementing counter appropriately) until enough material has been generated. The KM blocks are concatenated left to right I.e. KM(counter=1) || KM(counter=2)...
十分な材料が発生するまで、KEK、1を発生させるのは1つ以上のKMブロック(適切にカウンタを増加する)以上を発生させます。 KMブロックは左で正しいI.eに連結されます。 km(カウンタ=1)|| km(カウンタ=2)…
Note that the only source of secret entropy in this computation is ZZ. Even if a string longer than ZZ is generated, the effective key space of the KEK is limited by the size of ZZ, in addition to any security level considerations imposed by the parameters p and q. However, if partyAInfo is different for each message, a different KEK will be generated for each message. Note that partyAInfo MUST be used in Static-Static mode, but MAY appear in Ephemeral-Static mode.
この計算における秘密のエントロピーの唯一の源がZZであることに注意してください。 ZZより長いストリングが発生しても、KEKの有効な主要なスペースはZZのサイズによって制限されます、パラメタpとqによって課されたどんなセキュリティー・レベル問題に加えて。 しかしながら、各メッセージにおいて、partyAInfoが異なると、異なったKEKは各メッセージのために発生するでしょう。 partyAInfoがStatic静的なモードで使用しなければなりませんが、Ephemeral静的なモードで現れるかもしれないことに注意してください。
2.1.3. KEK Computation
2.1.3. KEK計算
Each key encryption algorithm requires a specific size key (n). The KEK is generated by mapping the left n-most bytes of KM onto the key. For 3DES, which requires 192 bits of keying material, the algorithm must be run twice, once with a counter value of 1 (to generate K1', K2', and the first 32 bits of K3') and once with a counter value of 2
それぞれの主要な暗号化アルゴリズムは特定のサイズキー(n)を必要とします。 KEKは、左の最もnバイトのKMをキーに写像することによって、発生します。 '3DESに関して、アルゴリズムを二度走らせなければなりません、1(K1、''最初の32ビットのケーツーK3'を発生させる)の対価による一度、2の対価でいったん。(3DESは合わせることの材料の192個のかけらを必要とします)。
Rescorla Standards Track [Page 4] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[4ページ]RFC2631ディフィー-ヘルマン
(to generate the last 32 bits of K3). K1',K2' and K3' are then parity adjusted to generate the 3 DES keys K1,K2 and K3. For RC2-128, which requires 128 bits of keying material, the algorithm is run once, with a counter value of 1, and the left-most 128 bits are directly converted to an RC2 key. Similarly, for RC2-40, which requires 40 bits of keying material, the algorithm is run once, with a counter value of 1, and the leftmost 40 bits are used as the key.
(K3の最後の32ビットを発生させる。) そして、'K1'、ケーツーと'K3'は3のDESキーK1、ケーツーとK3を発生させるように調整された同等です。 RC2-128に関しては、アルゴリズムは一度1の対価で走ります、そして、最も左の128ビットは直接RC2キーに変換されます。(RC2-128は合わせることの材料の128個のかけらを必要とします)。 同様に、RC2-40に関して、アルゴリズムは一度1の対価で走ります、そして、一番左40ビットはキーとして使用されます。(RC2-40は合わせることの材料の40個のかけらを必要とします)。
2.1.4. Keylengths for common algorithms
2.1.4. 一般的なアルゴリズムのためのKeylengths
Some common key encryption algorithms have KEKs of the following lengths.
いくつかの一般的な主要な暗号化アルゴリズムには、以下の長さのKEKsがあります。
3-key 3DES 192 bits
RC2-128 128 bits
RC2-40 40 bits
192ビットの3主要な3DES RC2-128 128ビットRC2-40 40ビット
RC2 effective key lengths are equal to RC2 real key lengths.
RC2の有効なキー長はRC2の本当のキー長と等しいです。
2.1.5. Public Key Validation
2.1.5. 公開鍵合法化
The following algorithm MAY be used to validate a received public key y.
以下のアルゴリズムは、容認された公開鍵yを有効にするのに使用されるかもしれません。
1. Verify that y lies within the interval [2,p-1]. If it does not,
the key is invalid.
2. Compute y^q mod p. If the result == 1, the key is valid.
Otherwise the key is invalid.
1. yが間隔[2、p-1]に属すことを確かめてください。 そうしないなら、キーは無効です。 2. y^qモッズpを計算してください。 結果=1であるなら、キーは有効です。 さもなければ、キーは無効です。
The primary purpose of public key validation is to prevent a small subgroup attack [LAW98] on the sender's key pair. If Ephemeral-Static mode is used, this check may not be necessary. See also [P1363] for more information on Public Key validation.
公開鍵合法化の第一の目的は送付者の主要な組で小さいサブグループ攻撃[LAW98]を防ぐことです。 Ephemeral静的なモードが使用されているなら、このチェックは必要でないかもしれません。 また、Public Key合法化の詳しい情報に関して[P1363]を見てください。
Note that this procedure may be subject to pending patents.
この手順は係属特許を受けることがあるかもしれないことに注意してください。
2.1.6. Example 1
2.1.6. 例1
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
0a 0b 0c 0d 0e 0f 10 11 12 13
ZZは20バイト00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13です。
The key wrap algorithm is 3DES-EDE wrap.
主要な包装アルゴリズムは3DES-EDE包装です。
No partyAInfo is used.
どんなpartyAInfoも使用されていません。
Consequently, the input to the first invocation of SHA-1 is:
その結果、SHA-1の最初の実施への入力は以下の通りです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ
Rescorla Standards Track [Page 5] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[5ページ]RFC2631ディフィー-ヘルマン
30 1d
30 13
06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID
04 04
00 00 00 01 ; Counter
a2 06
04 04
00 00 00 c0 ; key length
30 1d30 13 06 0b 2a86 48 86f7 0d01 09 10 03 06。 3DESはOID04 04 00 00 00 01を包装します。 a2 06 04 04 00 00 00c0を打ち返してください。 キー長
And the output is the 20 bytes:
そして、出力は20バイトです:
a0 96 61 39 23 76 f7 04 4d 90 52 a3 97 88 32 46 b6 7f 5f 1e
a0 96 61 39 23 76f7 04 4d90 52a3 97 88 32 46b6 7f 5f 1e
The input to the second invocation of SHA-1 is:
SHA-1の2番目の実施への入力は以下の通りです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
30 1d
30 13
06 0b 2a 86 48 86 f7 0d 01 09 10 03 06 ; 3DES wrap OID
04 04
00 00 00 02 ; Counter
a2 06
04 04
00 00 00 c0 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ30 1d30 13 06 0b 2a86 48 86f7 0d01 09 10 03 06。 3DESはOID04 04 00 00 00 02を包装します。 a2 06 04 04 00 00 00c0を打ち返してください。 キー長
And the output is the 20 bytes:
そして、出力は20バイトです:
f6 3e b5 fb 5f 56 d9 b6 a8 34 03 91 c2 d3 45 34 93 2e 11 30
f6 3e b5 fb 5f56d9 b6 a8 34 03 91c2 d3 45 34 93 2e11 30
Consequently, K1'=a0 96 61 39 23 76 f7 04 K2'=4d 90 52 a3 97 88 32 46 K3'=b6 7f 5f 1e f6 3e b5 fb
'その結果、K1'=a0 96 61 39 23 76f7 04ケーツー'は4d90 52a3 97 88 32 46K3と等しいこと'がb6 7f 5f 1e f6 3e b5 fbと等しいです。
Note: These keys are not parity adjusted
以下に注意してください。 これらのキーは調整された同等ではありません。
2.1.7. Example 2
2.1.7. 例2
ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
0a 0b 0c 0d 0e 0f 10 11 12 13
ZZは20バイト00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13です。
The key wrap algorithm is RC2-128 key wrap, so we need 128 bits (16 bytes) of keying material.
主要な包装アルゴリズムがRC2-128の主要な包装であるので、私たちは合わせることの材料の128個のかけら(16バイト)を必要とします。
The partyAInfo used is the 64 bytes
使用されるpartyAInfoは64バイトです。
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01
Rescorla Standards Track [Page 6] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[6ページ]RFC2631ディフィー-ヘルマン
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01
Consequently, the input to SHA-1 is:
その結果、SHA-1への入力は以下の通りです。
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
30 61
30 13
06 0b 2a 86 48 86 f7 0d 01 09 10 03 07 ; RC2 wrap OID
04 04
00 00 00 01 ; Counter
a0 42
04 40
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
a2 06
04 04
00 00 00 80 ; key length
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ30 61 30 13 06 0b 2a86 48 86f7 0d01 09 10 03 07。 RC2はOID04 04 00 00 00 01を包装します。 a0 42 04 40 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01を打ち返してください。 partyAInfo01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01a2 06 04 04 00 00 00 80。 キー長
And the output is the 20 bytes:
そして、出力は20バイトです:
48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0 3e 7b 5d e9
48 95 0c46e0 53 00 75 40 3c Ce72 88 96 04e0 3e 7b 5d e9
Consequently, K=48 95 0c 46 e0 53 00 75 40 3c ce 72 88 96 04 e0
その結果、Kは48 95 0c46e0 53 00 75 40 3c Ce72 88 96 04e0と等しいです。
2.2. Key and Parameter Requirements
2.2. キーとパラメタ要件
X9.42 requires that the group parameters be of the form p=jq + 1 where q is a large prime of length m and j>=2. An algorithm for generating primes of this form (derived from the algorithms in FIPS PUB 186-1[FIPS-186] and [X942]can be found in appendix A.
X9.42は、qが長さのmとj>=2の大きい主要であるところでグループパラメタがフォームp=jq+1のそうであることを必要とします。 この発生盛りのためのアルゴリズムを形成します。(FIPS PUB186-1のアルゴリズムから派生して、付録Aで[FIPS-186]と[X942]は見つけることができます。
X9.42 requires that the private key x be in the interval [2, (q - 2)]. x should be randomly generated in this interval. y is then computed by calculating g^x mod p. To comply with this memo, m MUST be >=160 bits in length, (consequently, q MUST be at least 160 bits long). When symmetric ciphers stronger than DES are to be used, a larger m may be advisable. p must be a minimum of 512 bits long.
xはこの間隔で手当たりしだいに発生するべきです。X9.42が、秘密鍵xが間隔にあるのを必要とする、[2 (q--2)] . 次に、yは計算高いg^xモッズpによって計算されます。 長さがmがこのメモに従うためには160>=ビットでなければならない、(その結果、qは長さ少なくとも160ビットでなければなりません。) DESより強い左右対称の暗号が使用されていることであるときに、より大きいmは賢明であるかもしれません。pは長さ最低512ビットでなければなりません。
2.2.1. Group Parameter Generation
2.2.1. グループパラメタ世代
Agents SHOULD generate domain parameters (g,p,q) using the following algorithm, derived from [FIPS-186] and [X942]. When this algorithm is used, the correctness of the generation procedure can be verified by a third party by the algorithm of 2.2.2.
エージェントSHOULDは、[FIPS-186]と[X942]から得られた以下のアルゴリズムを使用することでドメインパラメタ(g、p、q)を発生させます。 このアルゴリズムが使用されているとき、第三者は2.2のアルゴリズムで.2に世代手順の正当性について確かめることができます。
Rescorla Standards Track [Page 7] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[7ページ]RFC2631ディフィー-ヘルマン
2.2.1.1. Generation of p, q
2.2.1.1. pの世代、q
This algorithm generates a p, q pair where q is of length m and p is of length L.
このアルゴリズムはpを発生させて、qが長さmとpのものであるq組は長さLのものです。
1. Set m' = m/160 where / represents integer division with rounding
upwards. I.e. 200/160 = 2.
1. /が上向きに一周がある整数分割を代表する'セットm'=m/160。 すなわち 200/160 = 2.
2. Set L'= L/160
2. 'セットL'=L/160
3. Set N'= L/1024
3. 'セットN'=L/1024
4. Select an arbitrary bit string SEED such that the length of SEED
>= m
4. SEED>の長さがmと等しいように、任意のビット列SEEDを選択してください。
5. Set U = 0
5. U=0を設定してください。
6. For i = 0 to m' - 1
6. 'mへのi=0'--1
U = U + (SHA1[SEED + i] XOR SHA1[(SEED + m' + i)) * 2^(160 * i)
'UはU+(SHA1[SEED+i]XOR SHA1(SEED+m'+i))*2^と等しいです。(160*i)
Note that for m=160, this reduces to the algorithm of [FIPS-186]
m=160のために、これがアルゴリズムに減少することに注意してください。[FIPS-186]
U = SHA1[SEED] XOR SHA1[(SEED+1) mod 2^160 ].
UはSHA1[SEED]XOR SHA1[(SEED+1)モッズ2^160]と等しいです。
5. Form q from U by computing U mod (2^m) and setting the most
significant bit (the 2^(m-1) bit) and the least significant bit to
1. In terms of boolean operations, q = U OR 2^(m-1) OR 1. Note
that 2^(m-1) < q < 2^m
5. Uモッズ(2^m)を計算して、最も重要なビット(2^(m-1)ビット)と最下位ビットを1に設定することによって、Uからのqを形成してください。 論理演算子に関して、操作、qはU OR2^(m-1)OR1と等しいです。 その2^(m-1)<q<2^mに注意してください。
6. Use a robust primality algorithm to test whether q is prime.
6. qが主要であるか否かに関係なく、テストするのに強健なprimalityアルゴリズムを使用してください。
7. If q is not prime then go to 4.
7. qが主要でないなら、4まで行ってください。
8. Let counter = 0
8. カウンタ=0をさせてください。
9. Set R = seed + 2*m' + (L' * counter)
9. 'セットRは種子+2*mと等しい'という+'(L'*カウンタ)
10. Set V = 0
10. V=0を設定してください。
12. For i = 0 to L'-1 do
12. 'i=0からL'-1に関して、してください。
V = V + SHA1(R + i) * 2^(160 * i)
VはV+SHA1(R+i)*2^と等しいです。(160*i)
13. Set W = V mod 2^L
13. セットWはVモッズ2^Lと等しいです。
14. Set X = W OR 2^(L-1)
14. X=Wか2^を設定してください。(L-1)
Rescorla Standards Track [Page 8] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[8ページ]RFC2631ディフィー-ヘルマン
Note that 0 <= W < 2^(L-1) and hence X >= 2^(L-1)
0<=Wの<2^(L-1)としたがって、X>が2^と等しいことに注意してください。(L-1)
15. Set p = X - (X mod (2*q)) + 1
15. セットp=X--+ (Xモッズ(2*q))1
6. If p > 2^(L-1) use a robust primality test to test whether p is
prime. Else go to 18.
6. p>2^(L-1)が強健なprimalityを使用するなら、pが主要であるか否かに関係なく、テストするには、テストしてください。 18へのほかの碁。
17. If p is prime output p, q, seed, counter and stop.
17. pが主要な出力p、qであるなら、種を蒔いてください、そして、反対してください、そして、止まってください。
18. Set counter = counter + 1
18. カウンタ=カウンタ+1を設定してください。
19. If counter < (4096 * N) then go to 8.
19. カウンタ<(4096*N)であるなら、8まで行ってください。
20. Output "failure"
20. 出力「失敗」
Note: A robust primality test is one where the probability of a non- prime number passing the test is at most 2^-80. [FIPS-186] provides a suitable algorithm, as does [X942].
以下に注意してください。 体力を要している素数性テストはテストに合格する非素数の確率が高々2^-80であるものです。 [FIPS-186]は[X942]のように適当なアルゴリズムを提供します。
2.2.1.2. Generation of g
2.2.1.2. gの世代
This section gives an algorithm (derived from [FIPS-186]) for generating g.
このセクションは、gを発生させるようにアルゴリズムを与えます([FIPS-186]から、派生します)。
1. Let j = (p - 1)/q.
1. jを/qとの等しさにしてください(p--1)。
2. Set h = any integer, where 1 < h < p - 1 and h differs
from any value previously tried.
2. セットhはどんな整数とも等しいです、1<h<p--1とhが以前に試みられたどんな値とも異なっているところで。
3. Set g = h^j mod p
3. セットgはh^jモッズpと等しいです。
4. If g = 1 go to step 2
4. g=1がステップ2に行くなら
2.2.2. Group Parameter Validation
2.2.2. グループパラメタ合法化
The ASN.1 for DH keys in [PKIX] includes elements j and validation- Parms which MAY be used by recipients of a key to verify that the group parameters were correctly generated. Two checks are possible:
[PKIX]のDHキーのためのASN.1は要素jとグループパラメタが正しく発生したことを確かめるのにキーの受取人によって使用されるかもしれない合法化Parmsを含んでいます。 2つのチェックが可能です:
1. Verify that p=qj + 1. This demonstrates that the parameters meet
the X9.42 parameter criteria.
2. Verify that when the p,q generation procedure of [FIPS-186]
Appendix 2 is followed with seed 'seed', that p is found when
'counter' = pgenCounter.
1. そのp=qj+1つについて確かめてください。 これは、パラメタがX9.42パラメタ評価基準を満たすのを示します。 2. pであるときに、[FIPS-186]付録2のq世代手順が種子'種子'で従われていて、いつ'カウンタ'=pgenCounterがpに見つけられるかを確かめてください。
This demonstrates that the parameters were randomly chosen and
do not have a special form.
これは、パラメタが手当たりしだいに選ばれて、特別なフォームを持っていないのを示します。
Rescorla Standards Track [Page 9] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[9ページ]RFC2631ディフィー-ヘルマン
Whether agents provide validation information in their certificates is a local matter between the agents and their CA.
エージェントが彼らの証明書の合法化情報を提供するかどうかが、エージェントと彼らのカリフォルニアの間の地域にかかわる事柄です。
2.3. Ephemeral-Static Mode
2.3. はかなく静的なモード
In Ephemeral-Static mode, the recipient has a static (and certified) key pair, but the sender generates a new key pair for each message and sends it using the originatorKey production. If the sender's key is freshly generated for each message, the shared secret ZZ will be similarly different for each message and partyAInfo MAY be omitted, since it serves merely to decouple multiple KEKs generated by the same set of pairwise keys. If, however, the same ephemeral sender key is used for multiple messages (e.g. it is cached as a performance optimization) then a separate partyAInfo MUST be used for each message. All implementations of this standard MUST implement Ephemeral-Static mode.
受取人にはEphemeral静的なモードで、静的で(公認される)の主要な組がありますが、送付者は、各メッセージのために新しい主要な組を発生させて、originatorKey生産を使用することでそれを送ります。 送付者のキーが各メッセージのために新たに発生すると、共有秘密キーZZは同様に各メッセージにおいて異なるようになるでしょう、そして、partyAInfoは省略されるかもしれません、単に同じセットの対状キーで発生する複数のKEKsの衝撃を吸収するのに役立つので。 しかしながら、同じはかない送付者キーが複数のメッセージに使用されるなら(例えばそれはパフォーマンスの最適化としてキャッシュされます)、各メッセージに別々のpartyAInfoを使用しなければなりません。 この規格のすべての実現がEphemeral静的なモードを実行しなければなりません。
In order to resist small subgroup attacks, the recipient SHOULD perform the check described in 2.1.5. If an opponent cannot determine success or failure of a decryption operation by the recipient, the recipient MAY choose to omit this check. See also [LL97] for a method of generating keys which are not subject to small subgroup attack.
小さいサブグループ攻撃に抵抗するために、受取人SHOULDは2.1で.5に説明されたチェックを実行します。 相手が受取人による復号化操作の成否を決定できないなら、受取人は、このチェックを省略するのを選ぶかもしれません。 また、小さいサブグループ攻撃を受けることがないキーを発生させる方法に関して[LL97]を見てください。
2.4. Static-Static Mode
2.4. 静的に静的なモード
In Static-Static mode, both the sender and the recipient have a static (and certified) key pair. Since the sender's and recipient's keys are therefore the same for each message, ZZ will be the same for each message. Thus, partyAInfo MUST be used (and different for each message) in order to ensure that different messages use different KEKs. Implementations MAY implement Static-Static mode.
Static静的なモードで、送付者と受取人の両方には、静的で(公認される)の主要な組があります。 したがって、各メッセージに、送付者と受取人のキーが同じであるので、ZZは各メッセージに同じになるでしょう。 したがって、partyAInfoは、異なったメッセージが異なったKEKsを使用するのを確実にするために中古、そして、(各メッセージにおいて異なる。)でなければなりません。 実現はStatic静的なモードを実行するかもしれません。
In order to prevent small subgroup attacks, both originator and recipient SHOULD either perform the validation step described in Section 2.1.5 or verify that the CA has properly verified the validity of the key. See also [LL97] for a method of generating keys which are not subject to small subgroup attack.
小さいサブグループ攻撃を防ぐために、創始者と受取人SHOULDの両方が、セクション2.1.5で説明された合法化ステップを実行するか、またはカリフォルニアが適切にキーの正当性について確かめたことを確かめます。 また、小さいサブグループ攻撃を受けることがないキーを発生させる方法に関して[LL97]を見てください。
Acknowledgements
承認
The Key Agreement method described in this document is based on work done by the ANSI X9F1 working group. The author wishes to extend his thanks for their assistance.
本書では説明されたKey Agreement方法はANSI X9F1ワーキンググループによって行われた仕事に基づいています。 作者は彼らの支援のために感謝したがっています。
The author also wishes to thank Stephen Henson, Paul Hoffman, Russ Housley, Burt Kaliski, Brian Korver, John Linn, Jim Schaad, Mark Schertler, Peter Yee, and Robert Zuccherato for their expert advice and review.
また、作者は彼らの専門家の助言とレビューについてスティーブン・ヘンソン、ポール・ホフマン、ラスHousley、バートKaliski、ブライアンKorver、ジョン・リン、ジムSchaad、マークSchertler、ピーター・イー、およびロバートZuccheratoに感謝したがっています。
Rescorla Standards Track [Page 10] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[10ページ]RFC2631ディフィー-ヘルマン
References
参照
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。
[FIPS-46-1] Federal Information Processing Standards Publication
(FIPS PUB) 46-1, Data Encryption Standard, Reaffirmed
1988 January 22 (supersedes FIPS PUB 46, 1977 January
15).
[FIPS-46-1]連邦政府の情報処理規格公表(FIPSパブ)46-1(データ暗号化規格)は1月22日(1月15日にFIPSパブ46、1977に取って代わる)に1988を再び断言しました。
[FIPS-81] Federal Information Processing Standards Publication
(FIPS PUB) 81, DES Modes of Operation, 1980 December 2.
1980年のDES運転モード、12月2[FIPS-81]連邦政府の情報処理規格公表(FIPSパブ)81、日。
[FIPS-180] Federal Information Processing Standards Publication
(FIPS PUB) 180-1, "Secure Hash Standard", 1995 April 17.
[FIPS-180] 1995年の「安全な細切れ肉料理規格」、4月17連邦政府の情報処理規格公表(FIPSパブ)180-1、日。
[FIPS-186] Federal Information Processing Standards Publication
(FIPS PUB) 186, "Digital Signature Standard", 1994 May
19.
[FIPS-186]連邦政府の情報処理規格公表(FIPSパブ)186、「デジタル署名基準」、1994年の5月19日。
[P1363] "Standard Specifications for Public Key Cryptography",
IEEE P1363 working group draft, 1998, Annex D.
[P1363] 「公開鍵暗号のための標準の仕様」、IEEE P1363ワーキンググループドラフト、1998、Annex D。
[PKIX] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 2459, January 1999.
[PKIX] HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC2459、1999年1月。
[LAW98] L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
"An efficient protocol for authenticated key agreement",
Technical report CORR 98-05, University of Waterloo,
1998.
[LAW98] L.法とA.メネゼスとM.QuとJ.SolinasとS.Vanstone、「認証された主要な協定のための効率的なプロトコル」、TechnicalはCORR98-05、ウォータールー大学、1998を報告します。
[LL97] C.H. Lim and P.J. Lee, "A key recovery attack on discrete
log-based schemes using a prime order subgroup", B.S.
Kaliski, Jr., editor, Advances in Cryptology - Crypto
'97, Lecture Notes in Computer Science, vol. 1295, 1997,
Springer-Verlag, pp. 249-263.
Cryptologyの[LL97]C.H.リムとP.J.リー、「離散的なログベースの計画に対する主要なオーダーサブグループを使用するキーリカバリー攻撃」、理学士Kaliski、Jr.、エディタ、Advances--暗号97年、コンピュータScienceのLecture Notes、vol.1295、1997、Springer-Verlag、ページ 249-263.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[X942] "Agreement Of Symmetric Keys Using Diffie-Hellman and MQV
Algorithms", ANSI draft, 1998.
[X942] 「ディフィー-ヘルマンを使用する対称鍵とMQVアルゴリズムの協定」、ANSI草稿、1998。
Rescorla Standards Track [Page 11] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[11ページ]RFC2631ディフィー-ヘルマン
Security Considerations
セキュリティ問題
All the security in this system is provided by the secrecy of the private keying material. If either sender or recipient private keys are disclosed, all messages sent or received using that key are compromised. Similarly, loss of the private key results in an inability to read messages sent using that key.
個人的な合わせることの材料の秘密主義はこのシステムにおけるすべてのセキュリティを提供します。 送付者か受取人秘密鍵のどちらかが明らかにされるなら、そのキーを使用することで送るか、または受け取るすべてのメッセージが妥協します。 同様に、メッセージを読むことができないことにおける、秘密鍵結果の損失は、そのキーを使用することで発信しました。
Static Diffie-Hellman keys are vulnerable to a small subgroup attack [LAW98]. In practice, this issue arises for both sides in Static- Static mode and for the receiver during Ephemeral-Static mode. Sections 2.3 and 2.4 describe appropriate practices to protect against this attack. Alternatively, it is possible to generate keys in such a fashion that they are resistant to this attack. See [LL97]
静的なディフィー-ヘルマンキーは小さいサブグループ攻撃[LAW98]に傷つきやすいです。 実際には、この問題はStaticの静的なモードによる両側と受信機のためにEphemeral静的なモードの間、起こります。 セクション2.3と2.4は、この攻撃から守るために適切な習慣について説明します。 あるいはまた、それらはこの攻撃に抵抗力があるくらいのファッションでキーを発生させるのが可能です。 見てください。[LL97]
The security level provided by these methods depends on several
factors. It depends on the length of the symmetric key (typically, a
2^l security level if the length is l bits); the size of the prime q
(a 2^{m/2} security level); and the size of the prime p (where the
security level grows as a subexponential function of the size in
bits). A good design principle is to have a balanced system, where
all three security levels are approximately the same. If many keys
are derived from a given pair of primes p and q, it may be prudent to
have higher levels for the primes. In any case, the overall security
is limited by the lowest of the three levels.
これらの方法で提供されたセキュリティー・レベルはいくつかの要素に依存します。 それを対称鍵の長さに依存します(2^lセキュリティー・レベルは長さであるなら通常、lビットです)。 第1q(2^m/2セキュリティー・レベル)のサイズ。 そして、第1p(セキュリティー・レベルがビットのサイズのsubexponential関数として成長するところ)のサイズ。 良い設計原理はバランスのとれているシステムを持つことです。そこでは、すべての3つのセキュリティー・レベルがほとんど同じです。 盛りpとqの与えられた組から多くのキーを得るなら、盛りのための、より高いレベルを持っているのは慎重であるかもしれません。 どのような場合でも、総合的なセキュリティは3つのレベルで最も低いことによって制限されます。
Author's Address
作者のアドレス
Eric Rescorla RTFM Inc. 30 Newell Road, #16 East Palo Alto, CA 94303
エリックレスコラRTFM Inc.30ヌーエルRoad、東パロアルト、#16カリフォルニア 94303
EMail: ekr@rtfm.com
メール: ekr@rtfm.com
Rescorla Standards Track [Page 12] RFC 2631 Diffie-Hellman Key Agreement Method June 1999
協定方法1999年6月に主要なレスコラ標準化過程[12ページ]RFC2631ディフィー-ヘルマン
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Rescorla Standards Track [Page 13]
レスコラ標準化過程[13ページ]
一覧
スポンサーリンク
