Network Working Group J. Pawling
Request for Comments: 2876 WGSI, A Getronics Company
Category: Informational July 2000
Use of the KEA and SKIPJACK Algorithms in CMS
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
Abstract
抽象
This document describes the conventions for using the Key Exchange Algorithm (KEA) and SKIPJACK encryption algorithm in conjunction with the Cryptographic Message Syntax [CMS] enveloped-data and encrypted-data content types.
この文書は、暗号メッセージ構文[CMS]包まデータと暗号化されたデータのコンテンツタイプと一緒に鍵交換アルゴリズム（KEA）とSKIPJACK暗号化アルゴリズムを使用するための規則について説明します。
Throughout this document, the terms MUST, MUST NOT, SHOULD and MAY are used in capital letters. This conforms to the definitions in [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help make the intent of standards track documents as clear as possible. The same key words are used in this document to help implementers achieve interoperability. Software that claims compliance with this document MUST provide the capabilities as indicated by the MUST, MUST NOT, SHOULD and MAY terms. The KEA and SKIPJACK cryptographic algorithms are described in [SJ-KEA].
このドキュメントでは、用語は、すべきであり、MAYは大文字で使用されてはならないしなければなりません。これは、[MUSTSHOULD]の定義に従います。 [MUSTSHOULD]可能な限り明確な基準トラック文書の意図を支援するために、これらのキーワードの使用を定義します。同じキーワードが実装は、相互運用性を達成するのを助けるために、このドキュメントで使用されています。この文書の順守を主張するソフトウェアはMUSTで示され、NOT MUST、SHOULDとMAY用語としての機能を提供しなければなりません。 KEAとSKIPJACK暗号化アルゴリズムは、[SJ-KEA]に記載されています。
This section applies to the construction of both the enveloped-data and encrypted-data content types. Compliant software MUST meet the requirements stated in [CMS] Section 6.3, "Content-encryption Process". The input to the encryption process MUST be padded to a multiple of eight octets using the padding rules described in [CMS] Section 6.3. The content MUST be encrypted as a single string using the SKIPJACK algorithm in 64-bit Cipher Block Chaining (CBC) mode using randomly-generated 8-byte Initialization Vector (IV) and 80-bit SKIPJACK content-encryption key (CEK) values.
このセクションでは、エンベロープデータと暗号化されたデータのコンテンツタイプの両方の建設に適用されます。対応ソフトウェアは、[CMS]セクション6.3、「コンテンツ暗号化処理」に記載された要件を満たす必要があります。暗号化プロセスへの入力は、[CMS]セクション6.3に記載のパディング規則を使用して8つのオクテットの倍数にパディングされなければなりません。コンテンツは、ランダムに生成された8バイトの初期化ベクトル（IV）と80ビットカツオコンテンツ暗号化キー（CEK）の値を用いて、64ビットの暗号ブロック連鎖（CBC）モードでSKIPJACKアルゴリズムを使用して1つの文字列として暗号化する必要があります。
This section applies to the processing of both the enveloped-data and encrypted-data content types. The encryptedContent MUST be decrypted as a single string using the SKIPJACK algorithm in 64-bit CBC mode. The 80-bit SKIPJACK CEK and the 8-byte IV MUST be used as inputs to the SKIPJACK decryption process. Following decryption, the padding MUST be removed from the decrypted data. The padding rules are described in [CMS] Section 6.3, "Content-encryption Process".
このセクションでは、エンベロープデータと暗号化データのコンテンツタイプの両方の処理に適用されます。暗号化コンテンツは、64ビットのCBCモードでSKIPJACKアルゴリズムを使用して1つの文字列として復号化されなければなりません。 80ビットカツオCEKと8バイトのIVは、カツオ復号化処理への入力として使用されなければなりません。復号化に続いて、パディングが解読されたデータから削除する必要があります。パディングルールは[CMS]セクション6.3、「コンテンツ暗号化処理」で説明されています。
The CMS enveloped-data content type consists of an encrypted content and wrapped CEKs for one or more recipients. Compliant software MUST meet the requirements for constructing an enveloped-data content type stated in [CMS] Section 6, "Enveloped-data Content Type". [CMS] Section 6 should be studied before reading this section, because this section does not repeat the [CMS] text.
CMS包まデータのコンテンツタイプは、暗号化されたコンテンツと1人のまたは複数の受信者のために包まれたCEKで構成されています。対応ソフトウェアは、[CMS]セクション6、「包まデータコンテンツの種類」に記載包まデータのコンテンツタイプを構築するための要件を満たす必要があります。 [CMS]セクション6は、このセクションでは、[CMS]テキストを繰り返さないために、このセクションを読む前に検討する必要があります。
An 8-byte IV and 80-bit CEK MUST be randomly generated for each instance of an enveloped-data content type as inputs to the SKIPJACK algorithm for use to encrypt the content. The SKIPJACK CEK MUST only be used for encrypting the content of a single instance of an enveloped-data content type.
8バイトのIVと80ビットのCEKは、ランダムにコンテンツを暗号化するために使用するためのカツオアルゴリズムへの入力としてエンベロープデータのコンテンツ・タイプの各インスタンスに対して生成されなければなりません。 SKIPJACK CEKは、エンベロープデータ・コンテンツ・タイプの単一インスタンスのコンテンツを暗号化するために使用しなければなりません。
KEA and SKIPJACK can be used with the enveloped-data content type using either of the following key management techniques defined in [CMS] Section 6:
KEAとSKIPJACKは[CMS]セクション6で定義された次のキー管理技法のいずれかを使用して、エンベロープデータ・コンテンツ・タイプで使用することができます。
1) Key Agreement: The SKIPJACK CEK is uniquely wrapped for each recipient using a pairwise symmetric key-encryption key (KEK) generated using KEA using the originator's private KEA key, recipient's public KEA key and other values. Section 4.2 provides additional details.
1）主契約：SKIPJACK CEKを一意に発信者のプライベートKEAキー、受信者の公開KEAキーと他の値を使用してKEAを使用して生成されたペアワイズ対称鍵暗号化キーを（KEK）を使用して、受信者ごとに包まれています。 4.2節では、追加の詳細を提供します。
2) "Previously Distributed" Symmetric KEK: The SKIPJACK CEK is wrapped using a "previously distributed" symmetric KEK (such as a Mail List Key). The methods by which the symmetric KEK is generated and distributed are beyond the scope of this document. Section 4.3 provides more details.
2）対称KEKを「以前分散」：SKIPJACK CEK）は、メールリストキーとして「以前に分散」対称KEKを（使用して巻かれます。対称KEKを生成して分散させる方法は、この文書の範囲を超えています。 4.3節は、より多くの詳細を提供します。
[CMS] Section 6 also defines the concept of the key transport key management technique. The key transport technique MUST NOT be used with KEA.
[CMS]セクション6はまた、主要な輸送鍵管理手法の概念を定義します。キートランスポート技術がKEAを使用してはいけません。
The enveloped-data content type is Abstract Syntax Notation.1 (ASN.1) encoded using the EnvelopedData syntax. The fields of the EnvelopedData syntax must be populated as follows:
エンベロープデータコンテンツタイプは抽象構文記法1（ASN.1）はEnvelopedDataの構文を使用して符号化されます。次のようにEnvelopedDataの構文のフィールドは移入する必要があります。
The EnvelopedData version MUST be 2.
EnvelopedDataのバージョンは2でなければなりません。
If key agreement is being used, then the EnvelopedData originatorInfo field SHOULD be present and SHOULD include the originator's KEA X.509 v3 certificate containing the KEA public key associated with the KEA private key used to form each pairwise symmetric KEK used to wrap each copy of the SKIPJACK CEK. The issuers' X.509 v3 certificates required to form the complete certification path for the originator's KEA X.509 v3 certificate MAY be included in the EnvelopedData originatorInfo field. Self-signed certificates SHOULD NOT be included in the EnvelopedData originatorInfo field.
鍵合意が使用されている場合は、EnvelopedDataのoriginatorInfoフィールドが存在する必要があり、各ペアごとの対称性を形成するために使用さKEA秘密鍵に関連付けられたKEA公開鍵を含む創始者のKEA X.509 v3証明書を含むべきであるKEKは、それぞれのコピーをラップするために使用しましたSKIPJACK CEK。創始者のKEA X.509 v3証明書のための完全な証明書パスを形成するために必要な発行体のX.509 v3証明書がEnvelopedDataのoriginatorInfoフィールドに含まれるかもしれません。自己署名証明書がEnvelopedDataのoriginatorInfoフィールドに含まれるべきではありません。
The EnvelopedData RecipientInfo CHOICE is dependent on the key management technique used. Sections 4.2 and 4.3 provide more information.
EnvelopedDataののRecipientInfo CHOICEが使用するキー管理技術に依存しています。セクション4.2と4.3は、より多くの情報を提供しています。
The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm object identifier (OID). The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm parameters field MUST include the random 8-byte IV used as the input to the content encryption process.
EnvelopedDataのencryptedContentInfo contentEncryptionAlgorithmアルゴリズムフィールドは、ID-fortezzaConfidentialityAlgorithmオブジェクト識別子（OID）でなければなりません。 EnvelopedDataのencryptedContentInfo contentEncryptionAlgorithmパラメータフィールドは、コンテンツ暗号化プロセスへの入力として使用されるランダム8バイトのIVを含まなければなりません。
The EnvelopedData unprotectedAttrs MAY be present.
EnvelopedDataのunprotectedAttrsが存在してもよいです。
This section describes the conventions for using KEA and SKIPJACK with the CMS enveloped-data content type to support key agreement. When key agreement is used, then the RecipientInfo keyAgreeRecipientInfo CHOICE MUST be used.
このセクションでは、鍵の合意をサポートするために、CMS包まデータコンテンツタイプにKEAとSKIPJACKを使用するための規則について説明します。鍵合意を使用した場合、その後のRecipientInfo keyAgreeRecipientInfo CHOICEを使用しなければなりません。
If the EnvelopedData originatorInfo field does not include the originator's KEA X.509 v3 certificate, then each recipientInfos KeyAgreementRecipientInfo originator field MUST include the issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3 certificate. If the EnvelopedData originatorInfo field includes the originator's KEA X.509 v3 certificate, then each recipientInfos KeyAgreementRecipientInfo originator field MUST include either the subjectKeyIdentifier CHOICE containing the value from the subjectKeyIdentifier extension of the originator's KEA X.509 v3 certificate or the issuerAndSerialNumber CHOICE identifying the originator's KEA X.509 v3 certificate. To minimize the size of the EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be used.
EnvelopedDataのoriginatorInfoフィールドは創始者のKEA X.509 v3証明書が含まれていない場合は、各のrecipientInfos KeyAgreementRecipientInfo発信元フィールドは、発信者のKEA X.509 v3証明書を特定するissuerAndSerialNumber CHOICEを含まなければなりません。 EnvelopedDataのoriginatorInfoフィールドは、発信者のKEA X.509 v3証明書が含まれている場合、各のrecipientInfos KeyAgreementRecipientInfo元フィールドには、発信者を識別する発信者のKEA X.509 v3証明書又はissuerAndSerialNumber CHOICEのsubjectKeyIdentifier拡張から値を含むsubjectKeyIdentifierのCHOICEのいずれかを含まなければなりませんKEA X.509 v3の証明書。 EnvelopedDataのサイズを最小にするために、subjectKeyIdentifierのCHOICEが使用することをお勧めします。
In some environments, the KeyAgreementRecipientInfo originator field MAY include the originatorKey CHOICE. The originatorKey CHOICE SHOULD NOT be used with KEA for e-mail transactions. Within a controlled security architecture, a module may produce KEA key pairs for use in conjunction with internal/local storage of encrypted data. In this case, there may not be an X.509 certificate associated with a (possibly) short term or one time use public KEA key. When originatorKey is used, then the KEA public key MUST be conveyed in the publicKey BIT STRING as specified in [KEA] Section 3.1.2. The originatorKey algorithm identifier MUST be the id-keyExchangeAlgorithm OID. The originatorKey algorithm parameters field MUST contain the KEA "domain identifier" (ASN.1 encoded as an OCTET STRING) identifying the KEA algorithm parameters (i.e., p/q/g values) associated with the KEA public key. [KEA] Section 3.1.1 describes the method for computing the KEA domain identifier value.
一部の環境では、KeyAgreementRecipientInfo発信元フィールドはoriginatorKey CHOICEを含むかもしれません。 originatorKey CHOICEは、電子メールトランザクションにKEAには使用しないでください。制御されたセキュリティ・アーキテクチャ内で、モジュールは、暗号化されたデータの内部/ローカルストレージと組み合わせて使用するためのKEAキーのペアを生成することができます。この場合、（おそらく）短期または1回使用パブリックKEAキーに関連付けられたX.509証明書があってもなくてもよいです。 originatorKeyが使用される場合、[KEA]セクション3.1.2で指定されるように、次いで、KEA公開鍵は、公開鍵ビット列で搬送されなければなりません。 originatorKeyアルゴリズム識別子は、ID-のKeyExchangeAlgorithm OIDでなければなりません。 originatorKeyアルゴリズムパラメータフィールドは、KEA「ドメイン識別子」（OCTET STRINGとして符号化されたASN.1）KEAアルゴリズムパラメータKEA公開鍵に関連付けられている（即ち、P / Q / G値）を識別するを含まなければなりません。 [KEA]セクション3.1.1 KEAドメイン識別子の値を計算するための方法を記載しています。
The SKIPJACK CEK is uniquely wrapped for each recipient of the EnvelopedData using a pairwise KEK generated using the KEA material of the originator and the recipient along with the originator's User Keying Material (UKM) (i.e. Ra). The CMS EnvelopedData syntax provides two options for wrapping the SKIPJACK CEK for each recipient using a KEA-generated KEK. The "shared Originator UKM" option SHOULD be used when constructing EnvelopedData objects. The "unique originator UKM" option MAY be used when constructing EnvelopedData objects. Compliant software MUST be capable of processing EnvelopedData objects constructed using both options.
SKIPJACK CEKを一意ペアワイズKEKを用いEnvelopedDataの各受信者にラップされ、発信及び発信者のユーザ鍵材料（UKM）（すなわちRa）が一緒に受信者のKEAの材料を使用して生成。 CMS EnvelopedDataの構文はKEA-生成されたKEKを使用して受信者ごとにSKIPJACK CEKを包装するための2つのオプションが用意されています。 EnvelopedDataのオブジェクトを構築する際に、「共有発信UKM」オプションを使用する必要があります。 EnvelopedDataのオブジェクトを構築する際に、「独特の創始者UKM」オプションを使用することができます。コンプライアントソフトウェアは、両方のオプションを使用して構築EnvelopedDataのオブジェクトを処理できなければなりません。
1) Shared Originator UKM Option: CMS provides the ability for a single, shared originator's UKM to be used to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient. When using the shared originator UKM option, a single RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed to contain the wrapped SKIPJACK CEKs for all of the KEA recipients sharing the same KEA parameters. The KeyAgreeRecipientInfo structure includes multiple RecipientEncryptedKey fields that each contain the SKIPJACK CEK wrapped for a specific recipient.
1）共有発信UKMオプションは：CMSは、KEKが受信者ごとSKIPJACK CEKをラップするために使用される各ペアワイズを生成するために使用される単一の共有発信者UKMための能力を提供します。共有創始者UKMオプションを使用する場合、単一のRecipientInfo KeyAgreeRecipientInfo構造は同じKEAパラメータを共有KEA受取人のすべてに包まれたSKIPJACKたCEKを含むように構成しなければなりません。 KeyAgreeRecipientInfo構造は、それぞれが特定の受信者のためにラップされたカツオCEKを含む複数RecipientEncryptedKeyフィールドを含みます。
2) Unique Originator UKM Option: CMS also provides the ability for a unique originator UKM to be used to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient. When using the unique originator UKM option, a separate RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed for each recipient. Each KeyAgreeRecipientInfo structure includes a single RecipientEncryptedKey field containing the SKIPJACK CEK wrapped for the recipient. This option requires more overhead than the shared UKM option because the KeyAgreeRecipientInfo fields (i.e. version, originator, ukm, keyEncryptionAlgorithm) must be repeated for each recipient.
2）独自の発信UKMオプション：CMSはまた、KEKは、受信者ごとにSKIPJACK CEKをラップするために使用される各ペアごとに生成するために使用するユニークな創始者UKMのための機能を提供します。ユニーク発信UKMオプションを使用する場合、別のRecipientInfo KeyAgreeRecipientInfo構造は、各受信者のために構築されなければなりません。各KeyAgreeRecipientInfo構造は、受信者のラップされたSKIPJACK CEKを含む単一RecipientEncryptedKeyフィールドを含みます。 KeyAgreeRecipientInfoフィールド（すなわちバージョン、発信、UKM、keyEncryptionAlgorithm）は、各受信者に対して繰り返さなければならないため、このオプションは、共有UKMオプションよりも多くのオーバーヘッドを必要とします。
The next two paragraphs apply to both options.
次の二つの段落では、両方のオプションに適用されます。
The KeyAgreeRecipientInfo keyEncryptionAlgorithm algorithm field MUST include the id-kEAKeyEncryptionAlgorithm OID. The KeyAgreeRecipientInfo keyEncryptionAlgorithm parameters field MUST contain a KeyWrapAlgorithm as specified in [CMS] Appendix A, "ASN.1 Module". The algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. Since the FORTEZZA 80-bit wrap function includes an integrity check value, the wrapped SKIPJACK key is 96 bits long. The parameters field of KeyWrapAlgorithm MUST be absent.
KeyAgreeRecipientInfo keyEncryptionAlgorithmアルゴリズムフィールドは、ID-kEAKeyEncryptionAlgorithm OIDを含まなければなりません。 [CMS]付録A、 "ASN.1モジュール" に指定されているようKeyAgreeRecipientInfo keyEncryptionAlgorithmパラメータフィールドはKeyWrapAlgorithmを含まなければなりません。 KeyWrapAlgorithmのアルゴリズムフィールドはFORTEZZA 80ビットラップ関数は80ビットカツオCEKをラップするために使用されていることを示すID-fortezzaWrap80のOIDでなければなりません。 FORTEZZA 80ビットラップ機能は完全性チェック値を含んでいるので、ラップされたカツオキーは96ビット長です。 KeyWrapAlgorithmのパラメータフィールドが存在してはなりません。
If the originator is not already an explicit recipient, then a copy of the SKIPJACK CEK SHOULD be wrapped for the originator and included in the EnvelopedData. This allows the originator to decrypt the contents of the EnvelopedData.
発信元がすでに明示的な受信者でない場合は、SKIPJACK CEKのコピーは、発信のために包み、EnvelopedDataの中に含まれるべきです。これは、発信元がEnvelopedDataの内容を解読することができます。
This section describes how a shared originator UKM value is used as an input to KEA to generate each pairwise KEK used to wrap the SKIPJACK CEK for each recipient.
このセクションでは、共有発信UKM値は、KEKが受信者ごとSKIPJACK CEKをラップするために使用される各ペアワイズを生成するKEAへの入力として使用される方法について説明します。
When using the shared originator UKM option, a single RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed to contain the wrapped SKIPJACK CEKs for all of the KEA recipients using the same set of KEA parameters. If all recipients' KEA public keys were generated using the same set of KEA parameters, then there MUST only be a single RecipientInfo KeyAgreeRecipientInfo structure for all of the KEA recipients. If the recipients' KEA public keys were generated using different sets of KEA parameters, then multiple RecipientInfo KeyAgreeRecipientInfo fields MUST be constructed because the originatorIdentifierOrKey will be different for each distinct set of recipients' KEA parameters.
共有創始者UKMオプションを使用する場合、単一のRecipientInfo KeyAgreeRecipientInfo構造は、KEAパラメータの同じセットを使用してKEA受取人のすべてのために包まれたカツオたCEKを含むように構成しなければなりません。すべての受信者のKEA公開鍵がKEAパラメータの同じセットを使用して生成された場合は、唯一のKEA受取人のすべてのための単一のRecipientInfo KeyAgreeRecipientInfo構造があるに違いありません。受信者場合KEAパラメータKEA公開鍵がKEAパラメータの異なるセットを使用して生成されたoriginatorIdentifierOrKey受信者のそれぞれ異なるセットに対して異なることになるので、次に複数のRecipientInfo KeyAgreeRecipientInfoフィールドが構築されなければなりません。
A unique 128-byte originator's UKM MUST be generated for each distinct set of recipients' KEA parameters. The originator's UKM MUST be placed in each KeyAgreeRecipientInfo ukm OCTET STRING.
ユニークな128バイトの創始者のUKMは、受信者のKEAパラメータのそれぞれに異なるセットのために生成されなければなりません。創始者のUKMは、各KeyAgreeRecipientInfo UKMオクテット文字列に置かなければなりません。
The originator's and recipient's KEA parameters MUST be identical to use KEA to successfully generate a pairwise KEK. [KEA] describes how a KEA public key is conveyed in an X.509 v3 certificate. [KEA] states that the KEA parameters are not included in KEA certificates; instead, a "domain identifier" is supplied in the subjectPublicKeyInfo algorithm parameters field of every KEA certificate. The values of the KEA domain identifiers in the originator's and recipient's KEA X.509 v3 certificates can be compared to determine if the originator's and recipient's KEA parameters are identical.
発信者と受信者のKEAパラメータが正常にペアごとのKEKを生成するためにKEAを使用するのと同じでなければなりません。 [KEA]はKEA公開鍵がX.509 v3証明書に搬送する方法について説明します。 [KEA]はKEAパラメータはKEA証明書に含まれていないと述べています。代わりに、「ドメイン識別子は、」すべてのKEA証明書のSubjectPublicKeyInfoでアルゴリズムパラメータフィールドに供給されています。発信者と受信者のKEA X.509 v3の証明書でKEAドメイン識別子の値は、発信者と受信者のKEAパラメータが同一であるかどうかを決定するために比較することができます。
The following steps MUST be repeated for each recipient:
次の手順は、受信者ごとに繰り返さなければなりません：
1) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's private KEA key, recipient's 128 byte public KEA key (obtained from the recipient's KEA X.509 v3 certificate) and the recipient's 128-byte public KEA key used as the Rb value.
1）KEAは、発信者のUKM、発信者のプライベートKEA鍵に基づいてペアワイズのKEKを生成するために使用されなければならない、受信者のKEA X.509 v3証明書から取得した受信者の128バイトパブリックKEAキー（）と受信者の128バイトパブリックKEAキーを使用しますRbの値として。
2) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity checkvalue and produces a 96-bit result using the KEA-generated pairwise KEK.
2）SKIPJACK CEKはFORTEZZA 80ビットラップ関数への入力としてKEAで生成ペアワイズKEKを用いてラップされなければなりません。 FORTEZZA 80ビットラップ関数は、16ビットインテグリティcheckvalueと共に80ビットカツオCEKを受け取り、KEA-生成ペアワイズKEKを使用して96ビットの結果を生成します。
3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the recipient.
3）新しいRecipientEncryptedKeyシーケンスは、受信者のために構築されなければなりません。
4) The value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate MUST be placed in the recipient's RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other fields MUST be absent from the recipientEncryptedKey rid rKeyId SEQUENCE.
4）受信者のKEA X.509 v3証明書からsubjectKeyIdentifier拡張の値は、受信者のRecipientEncryptedKeyに配置する必要がありrKeyId subjectKeyIdentifierフィールドを取り除きます。 KeyAgreeRecipientIdentifier CHOICEはrKeyIdでなければなりません。日付や他のフィールドは取り除くrKeyId SEQUENCEをrecipientEncryptedKeyから存在してはなりません。
5) The wrapped SKIPJACK CEK MUST be placed in the recipient's RecipientEncryptedKey encryptedKey OCTET STRING.
5）包まれたSKIPJACK CEKは、受信者のRecipientEncryptedKey EncryptedKeyにオクテット文字列に置かなければなりません。
6) The recipient's RecipientEncryptedKey MUST be included in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
6）受信者のRecipientEncryptedKeyはRecipientEncryptedKey OF KeyAgreeRecipientInfo recipientEncryptedKeysシーケンスに含まれなければなりません。
This section describes how a unique originator UKM value is generated for each recipient to be used as an input to KEA to generate that recipient's pairwise KEK.
このセクションでは、各受信者がその受信者のペアワイズのKEKを生成するKEAへの入力として使用するための一意の発信UKM値が生成される方法について説明します。
The following steps MUST be repeated for each recipient:
次の手順は、受信者ごとに繰り返さなければなりません：
1) A new RecipientInfo KeyAgreeRecipientInfo structure MUST be constructed.
1）新規のRecipientInfo KeyAgreeRecipientInfo構造が構築されなければなりません。
2) A unique 128-byte originator's UKM MUST be generated. The originator's UKM MUST be placed in the KeyAgreeRecipientInfo ukm OCTET STRING.
2）独自の128バイトの創始者のUKMを生成しなければなりません。創始者のUKMはKeyAgreeRecipientInfo UKMオクテット文字列に置かなければなりません。
3) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's private KEA key, recipient's 128- byte public KEA key and recipient's 128-byte public KEA key used as the Rb value.
3）KEAは、発信者のUKM、発信者のプライベートKEAキー、受信者の128バイト、公開KEAキーとRbの値として使用され、受信者の128バイト、公開KEAキーに基づくペアごとのKEKを生成するために使用されなければなりません。
4) The SKIPJACK CEK MUST be wrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit wrap function. The FORTEZZA 80-bit wrap function takes the 80-bit SKIPJACK CEK along with a 16-bit integrity check value and produces a 96-bit result using the KEA-generated pairwise KEK.
4）SKIPJACK CEKはFORTEZZA 80ビットラップ関数への入力としてKEAで生成ペアワイズKEKを用いてラップされなければなりません。 FORTEZZA 80ビットラップ関数は、16ビットの完全性チェック値と共に80ビットカツオCEKを受け取り、KEA-生成ペアワイズKEKを使用して96ビットの結果を生成します。
5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.
5）新しいRecipientEncryptedKeyシーケンスを構成しなければなりません。
6) The value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate MUST be placed in the RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. The KeyAgreeRecipientIdentifier CHOICE MUST be rKeyId. The date and other fields MUST be absent from the RecipientEncryptedKey rid rKeyId SEQUENCE.
6）受信者のKEA X.509 v3証明書からsubjectKeyIdentifier拡張の値はRecipientEncryptedKeyに配置する必要がありrKeyId subjectKeyIdentifierフィールドを取り除きます。 KeyAgreeRecipientIdentifier CHOICEはrKeyIdでなければなりません。日付や他のフィールドは取り除くrKeyId SEQUENCEをRecipientEncryptedKeyから存在してはなりません。
7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey encryptedKey OCTET STRING.
7）ラップされたSKIPJACK CEKはRecipientEncryptedKey EncryptedKeyにOCTET STRINGの中に入れなければなりません。
8) The recipient's RecipientEncryptedKey MUST be the only RecipientEncryptedKey present in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
8）受信者のRecipientEncryptedKeyはRecipientEncryptedKey OF KeyAgreeRecipientInfo recipientEncryptedKeys配列中のみRecipientEncryptedKey存在していなければなりません。
9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo MUST be included in the EnvelopedData RecipientInfos SET OF RecipientInfo.
9）のRecipientInfoを含む受信者のKeyAgreeRecipientInfoはのRecipientInfo OF EnvelopedDataののrecipientInfosセットに含まれなければなりません。
This section describes the recipient processing using KEA to generate the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK.
このセクションでは、SKIPJACK KEKとSKIPJACK CEKの後続の復号化を生成するKEAを使用して受信者の処理について説明します。
1) Compliant software MUST be capable of processing EnvelopedData objects constructed using both the shared and the unique originator UKM options. To support the shared UKM option, the receiving software MUST be capable of searching for the recipient's RecipientEncryptedKey in a KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey. To support the unique UKM option, the receiving software MUST be capable of searching for the recipient's RecipientEncryptedKey in the EnvelopedData recipientInfos SET OF RecipientInfo, with each RecipientInfo containing exactly one RecipientEncryptedKey. For each RecipientEncryptedKey, if the rid rkeyId CHOICE is present, then the receiving software MUST attempt to match the value of the subjectKeyIdentifier extension from the recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid rKeyId subjectKeyIdentifier field. If the rid issuerAndSerialNumber CHOICE is present, then the receiving software MUST attempt to match the values of the issuer name and serial number from the recipient's KEA X.509 v3 certificate with the RecipientEncryptedKey rid issuerAndSerialNumber field.
1）準拠のソフトウェアは、共有ユニークな発信UKMオプションの両方使用して構築EnvelopedDataのオブジェクトを処理できなければなりません。共有UKMオプションをサポートするために、受信ソフトウェアはRecipientEncryptedKey OF KeyAgreeRecipientInfo recipientEncryptedKeysのSEQUENCEに受信者のRecipientEncryptedKeyを検索することができなければなりません。ユニークUKMオプションをサポートするために、受信ソフトウェアは、それぞれのRecipientInfoは正確に一つのRecipientEncryptedKeyを含むと、のRecipientInfo OF EnvelopedDataののrecipientInfos SETでの受信者のRecipientEncryptedKeyを検索することができなければなりません。 RID rkeyId CHOICEが存在する場合、各RecipientEncryptedKeyについては、その後、受信ソフトウェアはRecipientEncryptedKeyがrKeyId subjectKeyIdentifierフィールドを取り除くと、受信者のKEA X.509 v3証明書からsubjectKeyIdentifier拡張の値と一致しようとしなければなりません。 RID issuerAndSerialNumber CHOICEが存在する場合、受信ソフトウェアはRecipientEncryptedKeyがissuerAndSerialNumberフィールドを取り除くと、受信者のKEA X.509 v3証明書から発行者名とシリアル番号の値と一致しようとしなければなりません。
2) The receiving software MUST extract the originator's UKM from the ukm OCTET STRING contained in the same KeyAgreeRecipientInfo that includes the recipient's RecipientEncryptedKey.
2）受信ソフトウェアは、受信者のRecipientEncryptedKeyを含む同じKeyAgreeRecipientInfoに含まUKMオクテット文字列から発信者のUKMを抽出する必要があります。
3) The receiving software MUST locate the originator's KEA X.509 v3 certificate identified by the originator field contained in the same KeyAgreeRecipientInfo that includes the recipient's RecipientEncryptedKey.
3）受信ソフトウェアは、受信者のRecipientEncryptedKeyを含む同じKeyAgreeRecipientInfoに含まれる発信元フィールドによって識別される発信者のKEA X.509 v3証明書を見つけなければなりません。
4) KEA MUST be used to generate the pairwise KEK based on the originator's UKM, originator's 128-byte public KEA key (extracted from originator's KEA X.509 v3 certificate), recipient's private KEA key (associated with recipient's KEA X.509 v3 certificate identified by the RecipientEncryptedKey rid field) and the originator's 128-byte public KEA key used as the Rb value.
4）KEAは、発信者のUKMに基づくペアワイズKEK、発信者のKEA X.509 v3証明書から抽出された発信者128バイトパブリックKEAキー（）、受信者のKEA X.509 v3証明書に関連付けられた受信者の秘密KEAキーを（生成するために使用されなければなりませんRecipientEncryptedKey RIDフィールドによって識別される）とRbの値として使用する発信者128バイト、公開KEAキー。
5) The SKIPJACK CEK MUST be unwrapped using the KEA-generated pairwise KEK as input to the FORTEZZA 80-bit unwrap function.
5）SKIPJACK CEKはFORTEZZA 80ビットアンラップ関数への入力としてKEA-生成ペアワイズのKEKを使用してアンラップされなければなりません。
6) The unwrapped 80-bit SKIPJACK CEK resulting from the SKIPJACK CEK unwrap process and the 8-byte IV obtained from the EnvelopedData encryptedContentInfo contentEncryptionAlgorithm parameters field are used as inputs to the SKIPJACK content decryption process to decrypt the EnvelopedData encryptedContent.
6）SKIPJACK CEKのアンラップ処理に起因開封80ビットカツオCEKとEnvelopedDataのencryptedContentInfo contentEncryptionAlgorithmパラメータフィールドから得られた8バイトのIVはEnvelopedDataの暗号化コンテンツを復号するSKIPJACKコンテンツ復号化プロセスへの入力として使用されます。
This section describes the conventions for using SKIPJACK with the CMS enveloped-data content type to support "previously distributed" symmetric KEKs. When a "previously distributed" symmetric KEK is used to wrap the SKIPJACK CEK, then the RecipientInfo KEKRecipientInfo CHOICE MUST be used. The methods used to generate and distribute the symmetric KEK are beyond the scope of this document.
このセクションでは、「以前に配布さ」対称のKEKをサポートするために、CMS包まデータコンテンツタイプにSKIPJACKを使用するための規則について説明します。 「以前に分散」対称KEKがSKIPJACK CEKをラップするために使用された場合、その後のRecipientInfo KEKRecipientInfo選択は、使用されなければなりません。対称KEKを生成し、配布するために使用される方法は、この文書の範囲を超えています。
The KEKRecipientInfo fields MUST be populated as specified in [CMS] Section 6.2.3, "KEKRecipientInfo Type". The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be the id-fortezzaWrap80 OID indicating that the FORTEZZA 80-bit wrap function is used to wrap the 80-bit SKIPJACK CEK. The KEKRecipientInfo keyEncryptionAlgorithm parameters field MUST be absent. The KEKRecipientInfo encryptedKey field MUST include the SKIPJACK CEK wrapped using the "previously distributed" symmetric KEK as input to the FORTEZZA 80-bit wrap function.
[CMS]セクション6.2.3、「KEKRecipientInfoタイプ」に指定されているようKEKRecipientInfoフィールドが居住しなければなりません。 KEKRecipientInfo keyEncryptionAlgorithmアルゴリズムフィールドはFORTEZZA 80ビットラップ関数は80ビットカツオCEKをラップするために使用されていることを示すID-fortezzaWrap80のOIDでなければなりません。 KEKRecipientInfo keyEncryptionAlgorithmパラメータフィールドが存在してはなりません。 KEKRecipientInfo EncryptedKeyにフィールドがSKIPJACK CEKを含まなければなりませんFORTEZZA 80ビットラップ関数への入力として「以前に分散」対称KEKを用いて包ま。
The CMS encrypted-data content type consists of an encrypted content, but no recipient information. The method for conveying the SKIPJACK CEK required to decrypt the encrypted-data encrypted content is beyond the scope of this document. Compliant software MUST meet the requirements for constructing an encrypted-data content type stated [CMS] Section 8, "Encrypted-data Content Type". [CMS] Section 8 should be studied before reading this section, because this section does not repeat the [CMS] text.
CMS暗号化されたデータのコンテンツタイプは、暗号化されたコンテンツで構成されていませんが、何の受信者の情報。暗号化されたデータ暗号化コンテンツを復号するために必要なSKIPJACK CEKを搬送するための方法は、この文書の範囲外です。対応ソフトウェアは述べて暗号化されたデータのコンテンツタイプ[CMS]セクション8、「暗号化されたデータのコンテンツタイプ」を構築するための要件を満たす必要があります。 [CMS]セクション8は、このセクションでは、[CMS]テキストを繰り返さないために、このセクションを読む前に検討する必要があります。
The encrypted-data content type is ASN.1 encoded using the EncryptedData syntax. The fields of the EncryptedData syntax must be populated as follows:
暗号化されたデータのコンテンツタイプははEncryptedData構文を使用してエンコードされたASN.1です。次のようにはEncryptedData構文のフィールドは移入する必要があります。
The EncryptedData version MUST be set according to [CMS] Section 8.
EncryptedDataバージョンは[CMS]セクション8に従って設定されなければなりません。
The EncryptedData encryptedContentInfo contentEncryptionAlgorithm algorithm field MUST be the id-fortezzaConfidentialityAlgorithm OID. The EncryptedData encryptedContentInfo contentEncryptionAlgorithm parameters field MUST include the random 8-byte IV used as the input to the content encryption process.
EncryptedData encryptedContentInfo contentEncryptionAlgorithmアルゴリズムフィールドは、ID-fortezzaConfidentialityAlgorithm OIDでなければなりません。 EncryptedData encryptedContentInfo contentEncryptionAlgorithmパラメータフィールドは、コンテンツ暗号化プロセスへの入力として使用されるランダム8バイトのIVを含まなければなりません。
The EncryptedData unprotectedAttrs MAY be present.
EncryptedData unprotectedAttrsが存在してもよいです。
The United States Government has not published the description of the FORTEZZA 80-bit wrap function.
米国政府は、FORTEZZA 80ビットのラップ機能の説明を公表していません。
RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed attribute (defined as a SEQUENCE of SMIMECapability SEQUNCEs) to be used to specify a partial list of algorithms that the software announcing the SMIMECapabilities can support. When constructing a signedData object, compliant software MAY include the SMIMECapabilities signed attribute announcing that it supports the KEA and SKIPJACK algorithms.
RFC 2633 [MSG]、セクション2.5.2 SMIMEケーパビリティがSMIMEケーパビリティを発表ソフトウェアをサポートすることができるアルゴリズムの部分的なリストを指定するために使用される（SMIMECapability SEQUNCEsのシーケンスとして定義される）属性を締結定義します。 SignedDataオブジェクトを構築する際、対応ソフトウェアがSMIMEケーパビリティを含めてもよいことはKEAとSKIPJACKアルゴリズムをサポートすることを発表した属性に署名しました。
The SMIMECapability SEQUENCE representing KEA MUST include the id-kEAKeyEncryptionAlgorithm OID in the capabilityID field and MUST include a KeyWrapAlgorithm SEQUENCE in the parameters field. The algorithm field of KeyWrapAlgorithm MUST be the id-fortezzaWrap80 OID. The parameters field of KeyWrapAlgorithm MUST be absent. The SMIMECapability SEQUENCE for KEA SHOULD be included in the key management algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing KEA MUST be DER-encoded as the following hexadecimal string:
KEAを表すSMIMECapability配列はcapabilityIDフィールドにID-kEAKeyEncryptionAlgorithm OIDを含まなければなりませんし、パラメータフィールドにKeyWrapAlgorithm配列を含まなければなりません。 KeyWrapAlgorithmのアルゴリズムフィールドは、ID-fortezzaWrap80 OIDでなければなりません。 KeyWrapAlgorithmのパラメータフィールドが存在してはなりません。 KEAためSMIMECapability配列はSMIMEケーパビリティリストの鍵管理アルゴリズムの部分に含まれるべきです。 KEAを表すSMIMECapability配列は、以下の16進数の文字列としてDER-符号化されなければなりません。
3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117
0b06 0960 8648 0165 0201 0117 3018 0609 6086 4801 6502 0101 1830
The SMIMECapability SEQUENCE representing SKIPJACK MUST include the id-fortezzaConfidentialityAlgorithm OID in the capabilityID field and the parameters field MUST be absent. The SMIMECapability SEQUENCE for SKIPJACK SHOULD be included in the symmetric encryption algorithms portion of the SMIMECapabilities list. The SMIMECapability SEQUENCE representing SKIPJACK MUST be DER-encoded as the following hexadecimal string:
SKIPJACKはcapabilityIDフィールドのID-fortezzaConfidentialityAlgorithm OIDとパラメータフィールドを含まなければならない表すSMIMECapability配列が存在してはなりません。 SKIPJACKためSMIMECapability配列はSMIMEケーパビリティリストの対称暗号化アルゴリズム部に含まれるべきです。 SKIPJACKを表すSMIMECapability配列は、以下の16進数の文字列としてDER-符号化されなければなりません。
300b 0609 6086 4801 6502 0101 0400
300B 0609 6086 4801 6502 0101 0400
The following OIDs are specified in [INFO], but are repeated here for the reader's convenience:
以下のOIDは[INFO]で指定されているが、読者の便宜のためにここで繰り返されています。
id-keyExchangeAlgorithm OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) keyExchangeAlgorithm (22)} id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaWrap80Algorithm (23)}
id-kEAKeyEncryptionAlgorithm OBJECT IDENTIFIER ::= {joint-iso-
ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) kEAKeyEncryptionAlgorithm (24)}
id-fortezzaConfidentialityAlgorithm OBJECT IDENTIFIER ::= {joint-
iso-ccitt(2) country(16) us(840) organization(1) gov(101) dod(2)
infosec(1) algorithms(1) fortezzaConfidentialityAlgorithm (4)}
As specified in [USSUP1], when the id-fortezzaConfidentialityAlgorithm OID is present in the AlgorithmIdentifier algorithm field, then the AlgorithmIdentifier parameters field MUST be present and MUST include the SKIPJACK IV ASN.1 encoded using the following syntax:
【USSUP1]で指定されるように、ID-fortezzaConfidentialityAlgorithm OIDはのAlgorithmIdentifierアルゴリズムフィールドに存在する場合、その後のAlgorithmIdentifierパラメータフィールドが存在する必要があり、次の構文を使用して符号化されたカツオIVのASN.1を含める必要があります。
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
Note: [CMS] Section 2, "General Overview" describes the ASN.1 encoding conventions for the CMS content types including the enveloped-data and encrypted-data content types in which the id-fortezzaConfidentialityAlgorithm OID and parameters will be present.
注記：[CMS]第2節は、「一般的な概要は、」ID-fortezzaConfidentialityAlgorithm OIDとパラメータが存在するたに包まデータと暗号化されたデータのコンテンツタイプを含むCMSコンテンツタイプ用のASN.1エンコーディング規則について説明します。
References
リファレンス
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
[CMS] Housley氏、R.、 "暗号メッセージ構文"、RFC 2630、1999年6月。
[KEA] Housley, R. and W. Polk, "Representation of Key Exchange Algorithm (KEA) Keys in Internet X.509 Public Key Infrastructure Certificates", RFC 2528, March 1999.
[KEA] Housley氏、R.とW.ポーク、RFC 2528、1999年3月 "インターネットX.509公開鍵基盤証明書で鍵交換アルゴリズム（KEA）キーの表現"。
[INFO] Registry of INFOSEC Technical Objects, 22 July 1999.
[INFO] INFOSEC技術オブジェクトの登録、1999年7月22日。
[MSG] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[MSG] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0, http://csrc.nist.gov/encryption/skipjack-kea.htm.
[SJ-KEA] SKIPJACKとKEAアルゴリズムの仕様、バージョン2.0、http://csrc.nist.gov/encryption/skipjack-kea.htm。
[USSUP1] Allied Communication Publication 120 (ACP120) Common Security Protocol (CSP) United States (US) Supplement No. 1, June 1998; http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs.
[USSUP1]連合軍通信出版120（ACP120）共通セキュリティプロトコル（CSP）米国（US）補足1号、1998年6月。 http://www.armadillo.huntsville.al.us/Fortezza_docs/missi2.html#specs。
Acknowledgments
謝辞
The following people have made significant contributions to this memo: David Dalkowski, Phillip Griffin, Russ Housley, Pierce Leonberger, Rich Nicholas, Bob Relyea and Jim Schaad.
デビッドDalkowski、フィリップ・グリフィン、ラスHousley、ピアースレオンベルガー、リッチニコラス、ボブRelyeaとジムSchaad：次の人はこのメモへの重要な貢献をしました。
Author's Address
著者のアドレス
John Pawling Wang Government Services, Inc. (WGSI), A Getronics Company 141 National Business Pkwy, Suite 210 Annapolis Junction, MD 20701
ジョンPawling王政府サービス株式会社（WGSI）、ジェトロニクス株式会社141ナショナルビジネスパークウェイ、スイート210アナポリスジャンクション、MD 20701
Phone: (301) 939-2739 (410) 880-6095 EMail: john.pawling@wang.com
電話：（301）939-2739（410）880-6095 Eメール：john.pawling@wang.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。