Network Working Group J. Schaad
Request for Comments: 3537 Soaring Hawk Consulting
Category: Standards Track R. Housley
Vigil Security
May 2003
Wrapping a Hashed Message Authentication Code (HMAC) key
with a Triple-Data Encryption Standard (DES) Key
or an Advanced Encryption Standard (AES) Key
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 (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document defines two methods for wrapping an HMAC (Hashed Message Authentication Code) key. The first method defined uses a Triple DES (Data Encryption Standard) key to encrypt the HMAC key. The second method defined uses an AES (Advanced Encryption Standard) key to encrypt the HMAC key. One place that such an algorithm is used is for the Authenticated Data type in CMS (Cryptographic Message Syntax).
この文書では、HMAC（ハッシュメッセージ認証コード）キーを包装するための2つの方法を定義しています。定義された第一の方法は、HMACキーを暗号化するためのトリプルDES（データ暗号化規格）キーを使用します。定義された第二の方法は、HMACキーを暗号化するAES（高度暗号化規格）キーを使用します。このようなアルゴリズムが使用されている場所の一つは、CMSで認証されたデータの種類（暗号メッセージ構文）のためです。
Standard methods exist for encrypting a Triple-DES (3DES) content-encryption key (CEK) with a 3DES key-encryption key (KEK) [3DES-WRAP], and for encrypting an AES CEK with an AES KEK [AES-WRAP]. Triple-DES key wrap imposes parity restrictions, and in both instances there are restrictions on the size of the key being wrapped that make the encryption of HMAC [HMAC] keying material difficult.
標準的な方法は、及びでAES CEKを暗号化するための3DES鍵暗号鍵（KEK）[3DES-WRAP]とトリプルDES（3DES）コンテンツ暗号鍵（CEK）を暗号化するために存在するAES KEK [AES-WRAP] 。トリプルDESキーラップは、パリティ制約を課し、そして両方のインスタンスに困難HMAC [HMAC]鍵材料の暗号化を行う包まれているキーのサイズに制限があります。
This document specifies a mechanism for the encryption of an HMAC key of arbitrary length by a 3DES KEK or an AES KEK.
この文書では、3DES KEKまたはAES KEKによって任意の長さのHMACキーの暗号化のためのメカニズムを指定します。
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 BCP 14, RFC 2119 [STDWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [STDWORDS]に記載されているように解釈されます。
[HMAC] suggests that the key be at least as long as the output (L) of the hash function being used. When keys longer than the block size of the hash algorithm are used, they are hashed and the resulting hash value is used. Using keys much longer than L provides no security benefit, unless the random function used to create the key has low entropy output.
[HMAC]キーは、少なくとも限り、ハッシュ関数の出力（L）が使用されているようであることを示唆しています。ハッシュアルゴリズムのブロックサイズよりも長いキーが使用される場合、それらはハッシュされ、得られたハッシュ値が使用されています。キーを作成するために使用されるランダム関数は、低エントロピーの出力を持っていない限り、Lよりもはるかに長いキーを使用すると、何のセキュリティ上の利点を提供していません。
This section specifies the algorithms for wrapping and unwrapping an HMAC key with a 3DES KEK [3DES].
このセクションでは、ラッピングおよび3DES KEK [3DES]とHMACキーをアンラップするためのアルゴリズムを指定します。
The 3DES wrapping of HMAC keys is based on the algorithm defined in Section 3 of [3DES-WRAP]. The major differences are due to the fact that an HMAC key is of variable length and the HMAC key has no particular parity.
HMACキーの3DESラッピングは[3DES-WRAP]のセクション3で定義されたアルゴリズムに基づいています。主な違いは、HMACキーは可変長であり、HMACキーは特段のパリティを持っていないという事実に起因しています。
In the algorithm description, "a || b" is used to represent 'a' concatenated with 'b'.
アルゴリズムの説明で、「|| Bは」「」「B」との連結を表すために使用されます。
This algorithm encrypts an HMAC key with a 3DES KEK. The algorithm is:
このアルゴリズムは3DES KEKとHMACキーを暗号化します。アルゴリズムは次のとおりです。
1. Let the HMAC key be called KEY, and let the length of KEY in octets be called LENGTH. LENGTH is a single octet.
1. HMACキーはキーと呼ばれてみましょう、とオクテットでKEYの長さはLENGTHと呼ばれてみましょう。 LENGTHは、単一のオクテットです。
2. Let LKEY = LENGTH || KEY.
2. LKEY = LENGTHましょう||キー。
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple of 8, the PAD has a length of zero. If the length of LKEY is not a multiple of 8, then PAD contains the fewest number of random octets to make the length of LKEYPAD a multiple of 8.
3. LKEYPAD = LKEY ||をしてみましょうパッド。 LKEYの長さが8の倍数である場合、PADはゼロの長さを有します。 LKEYの長さが8の倍数でない場合は、PADがLKEYPADの長さが8の倍数を作るためにランダムオクテットの最小数が含まれています。
4. Compute an 8 octet key checksum value on LKEYPAD as described in Section 2 of [3DES-WRAP], call the result ICV.
4.計算[3DES-WRAP]のセクション2で説明したようにLKEYPADに8オクテットキーチェックサム値は、結果のICVを呼び出します。
5. Let LKEYPADICV = LKEYPAD || ICV.
5. LKEYPADICV = LKEYPAD ||をしてみましょうICV。
6. Generate 8 octets at random, call the result IV.
6.結果のIVを呼び出し、ランダムに8オクテットを生成します。
7. Encrypt LKEYPADICV in CBC mode using the 3DES KEK. Use the random value generated in the previous step as the initialization vector (IV). Call the ciphertext TEMP1.
3DES KEKを使用してCBCモードで7.暗号化LKEYPADICV。初期化ベクトル（IV）のような、前のステップで生成したランダム値を使用します。暗号文TEMP1を呼び出します。
8. Let TEMP2 = IV || TEMP1.
8. TEMP2 = IVましょう|| TEMP1。
9. Reverse the order of the octets in TEMP2. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP3.
9. TEMP2のオクテットの順序を逆にします。それは最も重要な（最初の）オクテットはそうで最下位（最後）のオクテットと交換、およびされています。結果TEMP3を呼び出します。
10. Encrypt TEMP3 in CBC mode using the 3DES KEK. Use an initialization vector (IV) of 0x4adda22c79e82105.
3DES KEKを使用してCBCモードで暗号化10 TEMP3。 0x4adda22c79e82105の初期化ベクトル（IV）を使用します。
Note: When the same HMAC key is wrapped in different 3DES KEKs, a fresh initialization vector (IV) must be generated for each invocation of the HMAC key wrap algorithm (step 6).
注：同一のHMACキーは異なる3DESのKEKに包まれた場合、新鮮な初期化ベクトル（IV）は、HMACキーラップアルゴリズム（ステップ6）の各呼び出しのために生成されなければなりません。
This algorithm decrypts an HMAC key using a 3DES KEK. The algorithm is:
このアルゴリズムは3DES KEKを使用してHMAC鍵を復号します。アルゴリズムは次のとおりです。
1. If the wrapped key is not a multiple of 8 octets, then error.
1.ラップされた鍵は8つのオクテット、エラーの倍数でない場合。
2. Decrypt the wrapped key in CBC mode using the 3DES KEK. Use an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
2. 3DES KEKを使用してCBCモードでラップされた鍵を復号化。 0x4adda22c79e82105の初期化ベクトル（IV）を使用します。出力TEMP3を呼び出します。
3. Reverse the order of the octets in TEMP3. That is, the most significant (first) octet is swapped with the least significant (last) octet, and so on. Call the result TEMP2.
3. TEMP3のオクテットの順序を逆にします。それは最も重要な（最初の）オクテットはそうで最下位（最後）のオクテットと交換、およびされています。結果TEMP2を呼び出します。
4. Decompose the TEMP2 into IV and TEMP1. IV is the most significant (first) 8 octets, and TEMP1 is composed of the remaining octets.
4. IVとTEMP1にTEMP2を分解する。 IVは、最も重要な（最初の）8つのオクテットであり、TEMP1、残りのオクテットで構成されています。
5. Decrypt TEMP1 in CBC mode using the 3DES KEK. Use the IV value from the previous step as the initialization vector. Call the plaintext LKEYPADICV.
5. 3DES KEKを使用してCBCモードでTEMP1を復号化。初期化ベクトルとして前のステップからIV値を使用します。平文LKEYPADICVを呼び出します。
6. Decompose the LKEYPADICV into LKEYPAD, and ICV. ICV is the least significant (last) 8 octets. LKEYPAD is composed of the remaining octets.
6. LKEYPAD、およびICVにLKEYPADICVを分解する。 ICVは最下位（最後の）8つのオクテットです。 LKEYPADは、残りのオクテットで構成されています。
7. Compute an 8 octet key checksum value on LKEYPAD as described in Section 2 of [3DES-WRAP]. If the computed key checksum value does not match the decrypted key checksum value, ICV, then error.
7.計算[3DES-WRAP]のセクション2で説明したようにLKEYPADに8オクテットキーチェックサム値。計算されたキーのチェックサム値は、復号化キーのチェックサム値、ICV、エラーと一致しない場合。
8. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the most significant (first) octet. KEY is the following LENGTH of octets. PAD is the remaining octets, if any.
8. LENGTH、KEY、パッドにLKEYPADを分解する。 LENGTHは、最も重要な（最初の）オクテットです。 KEYは、オクテット以下の長さです。もしあればPADが、残りのオクテットです。
9. If the length of PAD is more than 7 octets, then error.
9.パッドの長さが7つの以上のオクテット、エラーである場合。
10. Use KEY as an HMAC key.
HMACキーとして10を使用KEY。
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the HMAC Key Wrap with Triple-DES algorithm has been assigned the following algorithm identifier:
いくつかのセキュリティプロトコルは、ASN.1 [X.208-88、X.209-88]を採用し、これらのプロトコルは、暗号化アルゴリズムに名前を付けるためにアルゴリズム識別子を採用しています。これらのプロトコルをサポートするために、トリプルDESアルゴリズムとHMACキーラップは、以下のアルゴリズム識別子が割り当てられています。
id-alg-HMACwith3DESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 11 }
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifierパラメータフィールドはNULLでなければなりません。
KEK : 5840df6e 29b02af1 : ab493b70 5bf16ea1 : ae8338f4 dcc176a8
KEK：5840df6e 29b02af1：ab493b70 5bf16ea1：ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738
HMAC_KEY：c37b7e64 92584340：bed12207 80894115：5068f738
IV : 050d8c79 e0d56b75
IV：050d8c79 e0d56b75
PAD : 38be62
パッド：38be62
ICV : 1f363a31 cdaa9037
ICV：1f363a31 cdaa9037
LKEYPADICV : 14c37b7e 64925843 : 40bed122 07808941 : 155068f7 38be62fe : 1f363a31 cdaa9037
Kibdqvへ：14c37b7e 64925843：40bed122 07808941：155068f7 38be62fe：1f363a31 cdaa9037
TEMP1 : 157a8210 f432836b : a618b096 475c864b : 6612969c dfa445b1 : 5646bd00 500b2cc1
TEMP1：157a8210 f432836b：a618b096 475c864b：6612969cのdfa445b1：5646bd00 500b2cc1
TEMP3 : c12c0b50 00bd4656 : b145a4df 9c961266 : 4b865c47 96b018a6 : 6b8332f4 10827a15 : 756bd5e0 798c0d05
TEMP3：c12c0b50 00bd4656：9c961266 b145a4df：4b865c47 96b018a6：6b8332f4 10827a15：756bd5e0 798c0d05
Wrapped Key : 0f1d715d 75a0aaf6 : 6f02e371 c08b79e2 : a1253dc4 3040136b : dc161118 601f2863 : e2929b3b dd17697c
ラップされた鍵：0f1d715d 75a0aaf6：6f02e371 c08b79e2：a1253dc4 3040136b：dc161118 601f2863：e2929b3b dd17697c
This section specifies the algorithms for wrapping and unwrapping an HMAC key with an AES KEK [AES-WRAP].
このセクションでは、ラッピング及びAES KEK [AES-WRAP]とHMACキーをアンラップするためのアルゴリズムを指定します。
The AES wrapping of HMAC keys is based on the algorithm defined in [AES-WRAP]. The major difference is inclusion of padding due to the fact that the length of an HMAC key may not be a multiple of 64 bits.
HMACキーのAESラッピングは、[AES-WRAP]で定義されたアルゴリズムに基づいています。主な違いは、HMACキーの長さが64ビットの倍数ではないかもしれないという事実に起因パディングを含むことです。
In the algorithm description, "a || b" is used to represent 'a' concatenated with 'b'.
アルゴリズムの説明で、「|| Bは」「」「B」との連結を表すために使用されます。
This algorithm encrypts an HMAC key with an AES KEK. The algorithm is:
このアルゴリズムはAES KEKとHMACキーを暗号化します。アルゴリズムは次のとおりです。
1. Let the HMAC key be called KEY, and let the length of KEY in octets be called LENGTH. LENGTH is a single octet.
1. HMACキーはキーと呼ばれてみましょう、とオクテットでKEYの長さはLENGTHと呼ばれてみましょう。 LENGTHは、単一のオクテットです。
2. Let LKEY = LENGTH || KEY.
2. LKEY = LENGTHましょう||キー。
3. Let LKEYPAD = LKEY || PAD. If the length of LKEY is a multiple of 8, the PAD has a length of zero. If the length of LKEY is not a multiple of 8, then PAD contains the fewest number of random octets to make the length of LKEYPAD a multiple of 8.
3. LKEYPAD = LKEY ||をしてみましょうパッド。 LKEYの長さが8の倍数である場合、PADはゼロの長さを有します。 LKEYの長さが8の倍数でない場合は、PADがLKEYPADの長さが8の倍数を作るためにランダムオクテットの最小数が含まれています。
4. Encrypt LKEYPAD using the AES key wrap algorithm specified in section 2.2.1 of [AES-WRAP], using the AES KEK as the encryption key. The result is 8 octets longer than LKEYPAD.
暗号鍵としてAES KEKを使用して、[AES-WRAP]のセクション2.2.1で指定されたAESキーラップアルゴリズムを用いて前記暗号化LKEYPAD。結果はLKEYPADよりも長い8つのオクテットです。
The AES key unwrap algorithm decrypts an HMAC key using an AES KEK. The AES key unwrap algorithm is:
AESキーアンラップアルゴリズムはAES KEKを使用してHMAC鍵を復号します。 AESキーアンラップアルゴリズムは次のとおりです。
1. If the wrapped key is not a multiple of 8 octets, then error.
1.ラップされた鍵は8つのオクテット、エラーの倍数でない場合。
2. Decrypt the wrapped key using the AES key unwrap algorithm specified in section 2.2.2 of [AES-WRAP], using the AES KEK as the decryption key. If the unwrap algorithm internal integrity check fails, then error, otherwise call the result LKEYPAD.
前記復号鍵としてAES KEKを使用して、[AES-WRAP]のセクション2.2.2で指定されたAES鍵アンラップアルゴリズムを使用してラップされたキーを復号化。アンラップアルゴリズム内部の整合性チェックが失敗した場合、エラー、そうでない場合は結果LKEYPADを呼び出します。
3. Decompose the LKEYPAD into LENGTH, KEY, and PAD. LENGTH is the most significant (first) octet. KEY is the following LENGTH of octets. PAD is the remaining octets, if any.
3. LENGTH、KEY、パッドにLKEYPADを分解する。 LENGTHは、最も重要な（最初の）オクテットです。 KEYは、オクテット以下の長さです。もしあればPADが、残りのオクテットです。
4. If the length of PAD is more than 7 octets, then error.
4.パッドの長さが7つの以上のオクテット、エラーである場合。
5. Use KEY as an HMAC key.
HMACキーなど5.キーを押します。
Some security protocols employ ASN.1 [X.208-88, X.209-88], and these protocols employ algorithm identifiers to name cryptographic algorithms. To support these protocols, the HMAC Key Wrap with AES algorithm has been assigned the following algorithm identifier:
いくつかのセキュリティプロトコルは、ASN.1 [X.208-88、X.209-88]を採用し、これらのプロトコルは、暗号化アルゴリズムに名前を付けるためにアルゴリズム識別子を採用しています。これらのプロトコルをサポートするために、AESアルゴリズムとHMACキーラップは、以下のアルゴリズム識別子が割り当てられています。
id-alg-HMACwithAESwrap OBJECT IDENTIFIER ::= { iso(1)
member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
smime(16) alg(3) 12 }
The AlgorithmIdentifier parameter field MUST be NULL.
AlgorithmIdentifierパラメータフィールドはNULLでなければなりません。
KEK : 5840df6e 29b02af1 : ab493b70 5bf16ea1 : ae8338f4 dcc176a8
KEK：5840df6e 29b02af1：ab493b70 5bf16ea1：ae8338f4 dcc176a8
HMAC_KEY : c37b7e64 92584340 : bed12207 80894115 : 5068f738
HMAC_KEY：c37b7e64 92584340：bed12207 80894115：5068f738
PAD : 050d8c
パッド：050d8c
LKEYPAD : 14c37b7e 64925843 : 40bed122 07808941 : 155068f7 38050d8c
LKEYPAD：14c37b7e 64925843：40bed122 07808941：155068f7 38050d8c
Wrapped Key : 9fa0c146 5291ea6d : b55360c6 cb95123c : d47b38cc e84dd804 : fbcec5e3 75c3cb13
ラップされた鍵：9fa0c146 5291ea6d：b55360c6 cb95123c：d47b38ccのe84dd804：fbcec5e3 75c3cb13
Implementations must protect the key-encryption key (KEK). Compromise of the KEK may result in the disclosure of all HMAC keys that have been wrapped with the KEK, which may lead to loss of data integrity protection.
実装は、キー暗号化キー（KEK）を保護しなければなりません。 KEKの妥協は、データの整合性の保護の損失につながる可能性がKEKでラップされているすべてのHMACキーの開示をもたらすことができます。
The use of these key wrap functions provide confidentiality and data integrity, but they do not necessarily provide data origination authentication. Anyone possessing the KEK can create a message that passes the integrity check. If data origination authentication is also desired, then the KEK distribution mechanism must provide data origin authentication of the KEK. Alternatively, a digital signature may be used.
これらのキーラップ機能を使用するには、機密性とデータの整合性を提供し、彼らは必ずしもデータの発信認証を提供しません。 KEKを持つ誰もが整合性チェックに合格したメッセージを作成することができます。データ発信元認証はまた、所望される場合、KEK分配機構は、KEKのデータ発信元認証を提供しなければなりません。代替的に、デジタル署名を使用することができます。
Implementations must randomly generate initialization vectors (IVs) and padding. The generation of quality random numbers is difficult.
実装はランダムに初期化ベクトル（IV）とパディングを生成する必要があります。品質の乱数の生成が困難です。
RFC 1750 [RANDOM] offers important guidance in this area, and Appendix 3 of FIPS Pub 186 [DSS] provides one quality PRNG technique.
RFC 1750 [RANDOM]はこの領域で重要な指導を提供し、FIPSパブ186の付録3 [DSS]は1つの品質PRNGの技術を提供します。
The key wrap algorithms specified in this document have been reviewed for use with Triple-DES and AES, and have not been reviewed for use with other encryption algorithms.
この文書で指定されたキーラップアルゴリズムがトリプルDESやAESで使用するために検討されている、および他の暗号化アルゴリズムで使用するために検討されていません。
[3DES] American National Standards Institute. ANSI X9.52-1998, Triple Data Encryption Algorithm Modes of Operation. 1998.
[3DES]米国規格協会。 ANSI X9.52-1998、オペレーションのトリプルデータ暗号化アルゴリズムモード。 1998。
[3DES-WRAP] Housley, R., "Triple-DES and RC2 Key Wrapping", RFC 3217, December 2001.
[3DES-WRAP] Housley氏、R.、 "トリプルDESとRC2キーラッピング"、RFC 3217、2001年12月。
[AES] National Institute of Standards and Technology. FIPS Pub 197: Advanced Encryption Standard (AES). 26 November 2001.
[AES]アメリカ国立標準技術研究所。 FIPSパブ197：高度暗号化標準（AES）。 2001年11月26日。
[AES-WRAP] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[AES-WRAP] Schaad、J.とR. Housley氏、 "高度暗号化標準（AES）キーラップアルゴリズム"、RFC 3394、2002年9月。
[HMAC] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[HMAC] Krawczyk、H.、ベラー、M。およびR.カネッティ、 "HMAC：メッセージ認証のための鍵付きハッシュ化"、RFC 2104、1997年2月。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994.
標準技術[DSS]国立研究所。 FIPSパブ186：デジタル署名標準。 1994年5月19日。
[RANDOM] Eastlake 3rd, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RANDOM]イーストレイク3日、D.、クロッカー、S.とJ.シラー、 "セキュリティのためのランダム性に関する推奨事項"、RFC 1750、1994年12月。
[RFC2026] Bradner, S., "The Internet Standards Process - Revision 3", BCP 9, RFC 2026, October 1996.
[RFC2026]ブラドナーの、S.、 "インターネット標準化プロセス - リビジョン3"、BCP 9、RFC 2026、1996年10月。
[X.208-88] CCITT. Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1). 1988.
【X.208-88] CCITT。勧告X.208：抽象構文記法1（ASN.1）の仕様。 1988。
[X.209-88] CCITT. Recommendation X.209: Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1). 1988.
【X.209-88] CCITT。勧告X. 209：抽象構文記法1（ASN.1）のための基本的な符号化規則の仕様。 1988。
Jim Schaad Soaring Hawk Consulting
ジムSchaad高騰ホークコンサルティング
EMail: jimsch@exmsft.com
メールアドレス：jimsch@exmsft.com
Russell Housley Vigil Security 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousleyのビジルセキュリティ918春小山Driveハーンドン、VA 20170 USA
EMail: housley@vigilsec.com
メールアドレス：housley@vigilsec.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
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 assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
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機能のための基金は現在、インターネット協会によって提供されます。