RFC 2876 - Use of the KEA and SKIPJACK Algorithms in CMS 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc2876
タイトル : RFC 2876 - CMSでのKEAおよびSkipjackアルゴリズムの使用
翻訳編集 : 自動生成

[要約] RFC 2876は、CMSでKEAとSKIPJACKアルゴリズムの使用に関するガイドラインです。その目的は、セキュアなデータの交換と暗号化を実現するために、これらのアルゴリズムの適切な使用方法を提供することです。

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

CMSでのKEAおよびSkipjackアルゴリズムの使用

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

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暗号化アルゴリズムを使用するための規則について説明します。

1. Introduction

1. はじめに

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].

このドキュメント全体を通して、用語は大文字で使用される必要があり、そうでなければなりません。これは、[必須]の定義に準拠しています。[必須]は、これらのキーワードの使用を定義して、標準の意図を可能な限り明確に追跡するのに役立ちます。このドキュメントでは、同じキーワードが実装者が相互運用性を達成できるように使用しています。このドキュメントへのコンプライアンスを主張するソフトウェアは、必須、必要はありません。KEAおよびSkipJack暗号化アルゴリズムは[SJ-KEA]で説明されています。

2. Content Encryption Process

2. コンテンツ暗号化プロセス

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アルゴリズムを使用して単一の文字列として暗号化する必要があります。

3. Content Decryption Process

3. コンテンツ復号化プロセス

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".

このセクションでは、封筒と暗号化されたDATAコンテンツタイプの両方の処理に適用されます。暗号化されたコンテンツは、64ビットCBCモードでSkipJackアルゴリズムを使用して単一の文字列として復号化する必要があります。80ビットSkipjack CEKと8バイトIVは、SkipJack復号化プロセスへの入力として使用する必要があります。復号化に続いて、パディングを復号化されたデータから削除する必要があります。パディングルールについては、[CMS]セクション6.3「コンテンツ暗号化プロセス」で説明されています。

4. Enveloped-data Conventions

4. 包み込まれたデータの慣習

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「包括されたDATAコンテンツタイプ」に記載されている封筒コンテンツタイプを構築するための要件を満たす必要があります。[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アルゴリズムへの入力として、封筒コンテンツタイプの各インスタンスに対してランダムに生成する必要があります。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を使用して生成されたペアシンメトリックキー暗号化キー（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で使用しないでください。

4.1. EnvelopedData Fields

4.1. EnvelopedDataフィールド

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構文のフィールドは、次のように入力する必要があります。

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 X.509 V3証明書を含める必要があります。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の選択は、使用される主要な管理手法に依存しています。セクション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 ContentInfo contentencryptionalgorithm Algorithmフィールドは、id-fortezzaconfidentivelialityalgorithm object Identifier（oid）でなければなりません。EnvelopedData ContentInfo contentencryptionAlgorithmパラメーターフィールドには、コンテンツ暗号化プロセスへの入力として使用されるランダム8バイトIVを含める必要があります。

The EnvelopedData unprotectedAttrs MAY be present.

EnvelopedDataの無保護型が存在する可能性があります。

4.2. Key Agreement

4.2. 重要な合意

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.

このセクションでは、KEAとSkipjackを使用してCMSエンベロープデータのコンテンツタイプを使用して、重要な合意をサポートするための規則について説明します。主要な契約を使用する場合、cosiintinfo keyagreerecipientinfoの選択を使用する必要があります。

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フィールドにOriginatorのKEA X.509 V3証明書が含まれていない場合、各ReciontientInTINTINPOS KEYAGREEMENTRECIPIENTINFO ORIGINATORフィールドには、OriginatorのKEA X.509 V3証明書を識別する発行担当者の選択肢を含める必要があります。EnvelopedData OriginatorInfoフィールドにOriginatorのKEA X.509 V3証明書が含まれている場合、各ReciontientINTINTINPOS KEYAGREEMENTRECIPIENTINFO ORIGINATORフィールドには、Originator's KEA X.509 V3証明書の件名からの値を含む件名KeyIdentifier拡張を含む件名Keyidentifierの選択または発行済みの到着者選択を選択するISSUERANDSERINALNUMMERNUMMERCIETのいずれかを含める必要がある場合KEA X.509 V3証明書。EnvelopedDataのサイズを最小限に抑えるには、SubjectKeyIdentifierの選択を使用することをお勧めします。

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 Originatorのフィールドには、OriginatorKeyの選択肢が含まれる場合があります。OriginatorKeyの選択は、電子メールトランザクションにKEAで使用しないでください。制御されたセキュリティアーキテクチャ内で、モジュールは、暗号化されたデータの内部/ローカルストレージと組み合わせて使用するKEAキーペアを生成する場合があります。この場合、（おそらく）短期に関連付けられたX.509証明書がない場合、またはPublic KeAキーを1回使用しない場合があります。OriginatorKeyを使用する場合、[KEA]セクション3.1.2で指定されているように、KEAの公開キーをpublicKeyビット文字列に伝えなければなりません。OriginatorKeyアルゴリズム識別子は、ID-KeyExchangealGorithm oidでなければなりません。OriginatorKeyアルゴリズムパラメーターフィールドには、KEAアルゴリズムパラメーター（つまり、P/Q/G値）を識別するKEA「ドメイン識別子」（ASN.1）を含む必要があります。[KEA]セクション3.1.1では、KEAドメイン識別子値を計算する方法について説明します。

4.2.1. SKIPJACK CEK Wrap Process

4.2.1. SkipJack CEKラッププロセス

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は、発信者のKEA材料と受信者の材料を使用して生成されたペアワイズKEKを使用して、オリジネーターのユーザーキーイング素材（UKM）（つまりRA）を使用して生成されたペアワイズKEKを使用して、封筒の各受信者に対して独自に包まれています。CMS EnvelopedData Syntaxは、KEAで生成されたKEKを使用して各受信者のSkipJack CEKをラッピングするための2つのオプションを提供します。EnvelopedDataオブジェクトを構築するときは、「共有オリジネーターUKM」オプションを使用する必要があります。「ユニークなオリジネーター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は、各受信者のSkipjack CEKをラップするために使用される各ペアワイズKEKを生成するために、単一の共有オリジネーターのUKMを使用する機能を提供します。共有OriginatorのUKMオプションを使用する場合、同じKEAパラメーターを共有するすべてのKEAレシピエントにラップされたSkipJack CEKSを含むように、単一のReciontientINPIENTINPIENTINFO KEYAGREERECIPIENTINFO構造を構築する必要があります。KeyAgreerecipientInfo構造には、それぞれが特定の受信者にラップされたSkipJack CEKを含む複数のReciontientEncryptedKeyフィールドが含まれています。

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は、各受信者のSkipJack CEKをラップするために使用される各ペアワイズKEKを生成するために、ユニークなオリジナーターUKMを使用する機能も提供します。一意のOriginator ukmオプションを使用する場合、各受信者に対して個別のReciontientInfo keyagreerecipientinfo構造を構築する必要があります。各keyagreerecipientinfo構造には、受信者用にラップされたskipjack cekを含む単一のレシピエントエンクリプトキーフィールドが含まれています。このオプションは、各受信者に対してKeyAgreereCipientInfoフィールド（バージョン、オリジネーター、UKM、keyEncryptionalgorithm）を繰り返す必要があるため、共有UKMオプションよりも多くのオーバーヘッドが必要です。

The next two paragraphs apply to both options.

次の2つの段落は、両方のオプションに適用されます。

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を含める必要があります。keyagreerecipientinfo keyencryptionalgorithmパラメーターフィールドには、[CMS]付録A、「ASN.1モジュール」で指定されているキーワラパルゴリズムを含める必要があります。keywrapalgorithmのアルゴリズムフィールドは、fortezza 80ビットラップ関数が80ビットのSkipjack CEKをラップするために使用されることを示すID-Fortezzawrap80 oidでなければなりません。Fortezza 80ビットラップ機能には整合性チェック値が含まれているため、ラップされたSkipjackキーの長さは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のコピーをオリジネーターにラップし、封筒に含める必要があります。これにより、オリジネーターは封筒の内容を復号化できます。

4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM Value

4.2.1.1. 共有オリジネーターのUKM値を使用したSkipJackCEKラッププロセス

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値がKEAへの入力として使用され、各受信者のSkipJack CEKをラップするために使用される各ペアワイズKEKを生成する方法について説明します。

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.

Shared Originator UKMオプションを使用する場合、同じセットのKEAパラメーターを使用して、すべてのKEAレシピエントにラップされたSkipJack CEKSを含むように、単一のReciintINTINPIENTINPIENTINFO KEYAGREERECIPIENTINFO構造を構築する必要があります。すべての受信者の「KEAパブリックキーが同じセットのKEAパラメーターを使用して生成された場合、すべてのKEAレシピエントに対して単一のレシピティントインフーキーアグリーレシピエント構造がある必要があります。RecipientのKEAパブリックキーが異なるKEAパラメーターを使用して生成された場合、Originatoridedifierorkeyがレシピエントの個別のセットのKEAパラメーターごとに異なるため、複数の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 octet stringに配置する必要があります。

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パラメーターは、KEAを使用してペアワイズケクを正常に生成するために同一でなければなりません。[KEA]は、KEAの公開キーがX.509 V3証明書でどのように伝達されるかを説明しています。[KEA]は、KEAパラメーターがKEA証明書に含まれていないと述べています。代わりに、「ドメイン識別子」が、すべてのKEA証明書の[件名]アルゴリズムパラメーターフィールドに提供されます。オリジネーターおよび受信者の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キー、受信者の128バイトのパブリックキー（受信者のKEA X.509 V3証明書から入手）、および受信者の128バイトのパブリックキーに基づいてペアワイズケクを生成する必要があります。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生成のペアワイズケクを使用してラップする必要があります。Fortezza 80ビットラップ関数は、80ビットのSkipjack CEKと16ビットの整合性チェックバリューを採用し、KEA生成のペアワイズケクを使用して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証明書からの件名KeyIdentifier拡張機能の値は、受信者のReciotientEncryptedKey Rid rkeyidKeyidentidifierフィールドに配置する必要があります。keyagreerecipientidentidifierの選択は、rkeyidでなければなりません。日付およびその他のフィールドは、ReciintEncryptedKey Rid rkeyidシーケンスに存在しない必要があります。

5) The wrapped SKIPJACK CEK MUST be placed in the recipient's RecipientEncryptedKey encryptedKey OCTET STRING.

5) ラップされたSkipJack CEKは、受信者のRecipientEncryptedKey EncryptedKey Octet Stringに配置する必要があります。

6) The recipient's RecipientEncryptedKey MUST be included in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.

6) 受信者のReciontientEncryptedKeyは、keyAgreereCipientInfo RecipientEncryptedKeysのシーケンスに含まれている必要があります。

4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values

4.2.1.2. Skipjack CEKラッププロセスユニークなオリジナルのUKM値を使用します

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.

このセクションでは、各受信者がKEAの入力として使用してその受信者のペアワイズKEKを生成するために、各受信者がどのように生成されるかについて説明します。

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 octet stringに配置する必要があります。

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を使用して、OriginatorのUKM、OriginatorのPrivate KeAキー、受信者の128バイトのパブリックキー、および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生成のペアワイズケクを使用してラップする必要があります。Fortezza 80ビットラップ関数は、80ビットのSkipjack CEKと16ビットの整合性チェック値を採用し、KEA生成されたペアワイズケックを使用して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証明書からの件名KeyIdentifier拡張機能の値は、ReciintEncryptedKey Rid rkeyidKeyidentidifierフィールドに配置する必要があります。keyagreerecipientidentidifierの選択は、rkeyidでなければなりません。日付およびその他のフィールドは、ReciintEncryptedKey Rid rkeyidシーケンスに存在しない必要があります。

7) The wrapped SKIPJACK CEK MUST be placed in the RecipientEncryptedKey encryptedKey OCTET STRING.

7) ラップされたskipjack cekは、ReciontentEncryptedKey暗号化されたキーOctet Stringに配置する必要があります。

8) The recipient's RecipientEncryptedKey MUST be the only RecipientEncryptedKey present in the KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.

8) 受信者のReciontientEncryptedKeyは、KeyAgreerecipientInfo RecipientEncryptedKeysのシーケンスに存在する唯一のRecipientEncryptedKeyでなければなりません。

9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo MUST be included in the EnvelopedData RecipientInfos SET OF RecipientInfo.

9) 受信者のKeyAgreerecipientInfoを含む受信者は、emvelopedData RecipientInfosセットのRecipientINPOSに含める必要があります。

4.2.2. SKIPJACK CEK Unwrap Process

4.2.2. SkipJack CEK UNWRAPプロセス

This section describes the recipient processing using KEA to generate the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK.

このセクションでは、KEAを使用してSkipjack Kekを生成したレシピエント処理と、Skipjack CEKのその後の復号化について説明します。

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オプションの両方を使用して構築された封筒オブジェクトを処理できる必要があります。共有UKMオプションをサポートするには、受信ソフトウェアは、KeyAgreereCipientInfo RecipientEncryptedKeysのReciontientEncryptedKeyのシーケンスで受信者のReciontientEncryptedKeyを検索できる必要があります。一意のUKMオプションをサポートするには、受信ソフトウェアは、ReciontientInfoの封筒のemveloltData RecipientIntinfosセットで受信者のReciontientEncryptedKeyを検索することができなければなりません。RecipentEncryptedKeyごとに、RID rkeyidの選択が存在する場合、受信ソフトウェアは、受信者のKEA X.509 V3証明書からの件名KeaIdentifier拡張機能の値を、ReciontentEncryptedKey rid rkeyid Keypkeyidentidifierフィールドと一致させる必要があります。RID IssuerandSerialNumberの選択肢が存在する場合、受信ソフトウェアは、受信者のKEA X.509 V3証明書の発行者名とシリアル番号の値を、ReciontEntEncryptedKey RID発行担当者フィールドと一致させようと試みなければなりません。

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) 受信ソフトウェアは、受信者のReciotientEncryptedKeyを含む同じKeyAgreereCipientInfoに含まれるUKM Octet StringからOriginatorの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) 受信ソフトウェアは、受信者の受信者のReciontEncryptedKeyを含む同じ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に基づいてペアワイズケクを生成する必要があります。オリジネーターのUKM、オリジネーターの128バイトのパブリックキー（オリジネーターのKEA X.509 V3証明書から抽出された）、受信者のプライベートKEAキー（受信者のKEA X.509 V3証明書に関連付けられています。RecipentEncryptedKey RIDフィールド）と、RB値として使用されるOriginatorの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は、KEA生成されたペアワイズKEKを使用して、Fortezza 80ビットアンラップ関数への入力として解凍する必要があります。

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 UnWrapプロセスと封筒の暗号化されたContentinfo ContentenCryptionAlgorithmパラメーターから得られた8バイトIVから得られる8バイトIVフィールドは、SkipJackコンテンツの脱ネクタイプロセスへの入力として使用されます。

4.3. "Previously Distributed" Symmetric KEK

4.3. 「以前に分散した」対称Kek

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.

このセクションでは、SkipjackをCMS包括的なデータコンテンツタイプで使用するための規則について説明し、「以前に分散した」対称キークをサポートします。「以前に分散した」対称Kekを使用してSkipJack CEKをラップする場合、Reciintinfo 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.

kekrecipientinfoフィールドは、[CMS]セクション6.2.3「kekrecipientinfoタイプ」で指定されているように入力する必要があります。KekRecipientInfo KeyEncryptionAlgorithm Algorithmフィールドは、Fortezza 80ビットラップ関数が80ビットSkipjack Cekをラップするために使用されることを示すID-Fortezzawrap80 oidでなければなりません。kekrecipientinfo keyencryptionalgorithmパラメーターフィールドはない必要があります。KekrecipientInfoの暗号化されたキーフィールドには、「以前に分散した」対称Kekを使用してFortezza 80ビットラップ関数への入力としてLappedを使用する必要があります。

5. Encrypted-data Conventions

5. 暗号化されたデータの規則

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暗号化されたDATAコンテンツタイプは、暗号化されたコンテンツで構成されていますが、受信者情報はありません。暗号化されたData暗号化されたコンテンツを復号化するために必要なSkipjack CEKを伝える方法は、このドキュメントの範囲を超えています。準拠したソフトウェアは、暗号化されたDATAコンテンツタイプを構築するための要件を満たす必要があります[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:

暗号化されたDataコンテンツタイプは、暗号化された構文を使用してASN.1エンコードされています。暗号化された構文のフィールドは、次のように入力する必要があります。

The EncryptedData version MUST be set according to [CMS] Section 8.

暗号化されたバージョンは、[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.

暗号化されたdata contentinfo contentencryptionalgorithmアルゴリズムフィールドは、id-fortezzaconfidentivelialityalgorithm oidでなければなりません。IncryptedData EncryptedContentInfo contentencryptionalgorithmパラメーターフィールドには、コンテンツ暗号化プロセスへの入力として使用されるランダムな8バイトIVを含める必要があります。

The EncryptedData unprotectedAttrs MAY be present.

暗号化されていないdataが保護されていない場合があります。

6. FORTEZZA 80-bit Wrap Function

6. Fortezza 80ビットラップ機能

The United States Government has not published the description of the FORTEZZA 80-bit wrap function.

米国政府は、Fortezza 80ビットラップ機能の説明を公開していません。

7. SMIMECapabilities Attribute Conventions

7. SmimeCapabilities属性の規則

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では、SmimeCapability属性（SmimeCapability Sequnceのシーケンスとして定義されている）を使用して、SmimeCapabilityを発表するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定することを定義しています。SignedDataオブジェクトを構築する場合、準拠したソフトウェアには、KEAおよびSkipjackアルゴリズムをサポートすることを発表するSmimeCapabilities Signed属性が含まれる場合があります。

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シーケンスには、機能IDフィールドにID-KeakeyEncryptionAlgorithm OIDを含める必要があり、パラメーターフィールドにKeyWrapalgorithmシーケンスを含める必要があります。keywrapalgorithmのアルゴリズムフィールドは、id-fortezzawrap80 oidでなければなりません。keywrapalgorithmのパラメーターフィールドはない必要があります。KEAのSmimeCapabilityシーケンスは、SmimeCapability Listの主要な管理アルゴリズム部分に含める必要があります。KEAを表すSmimeCapabilityシーケンスは、次の16進数文字列としてder-Encodedにする必要があります。

3018 0609 6086 4801 6502 0101 1830 0b06 0960 8648 0165 0201 0117

3018 0609 6086 4801 6502 0101 1830 0B06 0960 8648 0165 0201 0117

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を表すSmimeCapabilityシーケンスには、ID-FortezzaconfidentivelialityAlgorithm oid oid oid in the field inforeとパラメータフィールドを存在しなければなりません。SkipJackのSmimeCapabilityシーケンスは、SmimeCapability Listの対称暗号化アルゴリズム部分に含める必要があります。Skipjackを表すSmimeCapabilityシーケンスは、次の16進数文字列としてder-Encodedを使用する必要があります。

300b 0609 6086 4801 6502 0101 0400

300B 0609 6086 4801 6502 0101 0400

8. Object Identifier Definitions

8. オブジェクト識別子定義

The following OIDs are specified in [INFO], but are repeated here for the reader's convenience:

次のOIDは[情報]で指定されていますが、読者の利便性のためにここで繰り返されます。

   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がアルゴリズムIdentidifierアルゴリズムフィールドに存在する場合、アルゴリズムのdidentifierパラメーターフィールドは存在する必要があり、次のシンタックスを使用してエンコードされたskipjack kiv 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-Fortezzaconaconaconconaconconconconconconconconconted-Dataコンテンツタイプを含む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。and W. Polk、「インターネットX.509公開キーインフラ証明書のキー交換アルゴリズム（KEA）キーの表現」、RFC 2528、1999年3月。

[INFO] Registry of INFOSEC Technical Objects, 22 July 1999.

[情報] 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.

[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Allied Communication Publication 120（ACP120）Common Security Protocol（CSP）米国（米国）サプリメントNo. 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.

次の人々は、このメモに多大な貢献をしています：デビッド・ダルコウスキー、フィリップ・グリフィン、ラス・ヒューズリー、ピアス・レオンバーガー、リッチ・ニコラス、ボブ・リーリー、ジム・シャード。

Author's Address

著者の連絡先

John Pawling Wang Government Services, Inc. (WGSI), A Getronics Company 141 National Business Pkwy, Suite 210 Annapolis Junction, MD 20701

John Pawning Wang Government Services、Inc。（WGSI）、A Getronics Company 141 National Business Pkwy、Suite 210 Annapolis Junction、MD 20701

Phone: (301) 939-2739 (410) 880-6095 EMail: john.pawling@wang.com

電話：（301）939-2739（410）880-6095メール：john.pawling@wang.com

Full Copyright Statement

完全な著作権声明

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エディター機能の資金は現在、インターネット協会によって提供されています。