RFC2876 日本語訳
2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July 2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Pawling Request for Comments: 2876 WGSI, A Getronics Company Category: Informational July 2000
Pawlingがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2876WGSI、Getronics会社カテゴリ: 情報の2000年7月
Use of the KEA and SKIPJACK Algorithms in CMS
cmにおけるケアとトビウオの類アルゴリズムの使用
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
このドキュメントは、Cryptographic Message Syntax[CMS]のおおわれたデータとデータのコード化された内容タイプに関連してKey Exchange Algorithm(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].
このドキュメント中では、用語が使用しなければならない、大文字でNOT、SHOULD、および5月を使用しなければなりません。 これは[MUSTSHOULD]との定義に従います。 [MUSTSHOULD]は、標準化過程ドキュメントの意図をできるだけ明確にするのを助けるためにこれらのキーワードの使用を定義します。 同じキーワードは、implementersが相互運用性を達成するのを助けるのに本書では使用されます。 このドキュメントへのコンプライアンスを要求するソフトウェアが示されるように能力を提供しなければならない、NOT、SHOULD、および5月の用語暗号アルゴリズムが説明される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バイトの初期設定Vector(IV)と80ビットのSKIPJACK満足している暗号化主要な(CEK)値を使用しながら64ビットのCipher Block Chaining(CBC)モードでSKIPJACKアルゴリズムを使用して、一連として内容をコード化しなければなりません。
Pawling Informational [Page 1] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[1ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
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".
このセクションは両方のおおわれたデータとコード化されたデータの満足しているタイプの処理に適用されます。 64ビットのCBCモードでSKIPJACKアルゴリズムを使用して、一連としてencryptedContentを解読しなければなりません。 SKIPJACK復号化へのSKIPJACK CEKと8バイトのIVが使用されているに違いない80ビット入力は処理されます。 復号化に続いて、解読されたデータから詰め物を取り除かなければなりません。 詰め物規則は[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人以上の受取人のためのコード化された内容と包装されたCEKsから成ります。 対応するソフトウェアは、[CMS]セクション6に述べられたタイプ、「おおわれたデータの満足しているタイプ」というおおわれたデータ内容を構成するために条件を満たさなければなりません。 このセクションが[CMS]テキストを繰り返さないのでこのセクションを読む前に、[CMS]セクション6は研究されるべきです。
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 MUSTは手当たりしだいにそうです。使用のためのSKIPJACKアルゴリズムへの入力としてのおおわれたデータの満足しているタイプの各例が内容をコード化するように、発生します。 SKIPJACK CEK MUST、おおわれたデータの満足しているタイプのただ一つの例の内容をコード化するのに単に使用されてください。
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:
[CMS]セクション6で定義された以下のかぎ管理のテクニックのどちらかを使用するおおわれたデータの満足しているタイプでKEAとSKIPJACKを使用できます:
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)を使用することで唯一包装されます、受取人の公共のKEA主要で他の値。 セクション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(メールList Keyなどの)を使用することで包装されます。 左右対称の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と共に主要な輸送のテクニックを使用してはいけません。
Pawling Informational [Page 2] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[2ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
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:
おおわれたデータの満足しているタイプはEnvelopedData構文を使用することでコード化された抽象的なSyntax Notation.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がSHOULDをさばくという主要な協定がプレゼントとSHOULDであるなら、左右対称のKEKがSKIPJACK CEKの各コピーを包装するのに使用した各対状を形成するのに使用されるKEA秘密鍵に関連しているKEA公開鍵を含む創始者のKEA X.509 v3証明書を含めてください。 証明書が創始者のKEA X.509 v3証明書のために完全な証明経路を形成するのを必要とした発行人のX.509 v3はEnvelopedData originatorInfo分野に含まれるかもしれません。 自己署名入りの証書SHOULD NOT、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アルゴリズム分野はイド-fortezzaConfidentialityAlgorithm物の識別子であるに違いありません(OID)。 EnvelopedData encryptedContentInfo contentEncryptionAlgorithmパラメタ分野は入力として満足している暗号化の過程に使用される無作為の8バイトのIVを含まなければなりません。
The EnvelopedData unprotectedAttrs MAY be present.
EnvelopedData unprotectedAttrsは存在しているかもしれません。
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を使用するためにコンベンションについて説明します、そして、CMSおおわれたデータ内容がある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
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証明書のsubjectKeyIdentifier拡張子からの値を含むsubjectKeyIdentifier CHOICEかissuerAndSerialNumber CHOICE特定のどちらかを含まなければなりません。
Pawling Informational [Page 3] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[3ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
originator's KEA X.509 v3 certificate. To minimize the size of the EnvelopedData, it is recommended that the subjectKeyIdentifier CHOICE be used.
創始者の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 SHOULD、メール取引にKEAと共に使用されないでください。 制御セキュリティー体系の中では、モジュールは使用のためにコード化されたデータの内部の、または、地方の格納に関連してKEA主要な組を生産するかもしれません。 この場合、(ことによると)短期間か1回の使用公共のKEAキーに関連しているX.509証明書がないかもしれません。 originatorKeyが使用されていると、[KEA]セクション3.1.2における指定されるとしてのpublicKey BIT STRINGでKEA公開鍵を伝えなければなりません。 originatorKeyアルゴリズム識別子はイドkeyExchangeAlgorithm OIDであるに違いありません。 KEA公開鍵に関連しているKEAアルゴリズムパラメタ(すなわち、p/q/g値)を特定して、originatorKeyアルゴリズムパラメタ分野はKEA「ドメイン識別子」(OCTET STRINGとしてコード化されたASN.1)を含まなければなりません。 [KEA]セクション3.1 .1 KEAドメイン識別子価値を計算するための方法を説明します。
4.2.1. SKIPJACK CEK Wrap Process
4.2.1. トビウオの類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は、EnvelopedDataの各受取人のために創始者のUser Keying Material(UKM)(すなわち、Ra)に伴う創始者と受取人のKEAの材料を使用することでKEKが作った対状を使用することで唯一包装されます。 CMS EnvelopedData構文は各受取人のためにKEAが発生しているKEKを使用することでSKIPJACK CEKを包装するのに2つのオプションを提供します。 「共有されたOriginator UKM」はSHOULDにゆだねます。EnvelopedData物を組み立てるときには、使用されてください。 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は単一の、そして、共有された創始者のUKMが各受取人のためにSKIPJACK CEKを包装するのに使用される各対状KEKを発生させるのに使用される能力を提供します。 共有された創始者UKMオプションを使用するとき、同じKEAパラメタを共有しているKEA受取人のすべてのための包装されたSKIPJACK CEKsを含むようにただ一つのRecipientInfo KeyAgreeRecipientInfo構造を構成しなければなりません。 KeyAgreeRecipientInfo構造はそれぞれ特定の受取人のために包装されたSKIPJACK CEKを含む複数のRecipientEncryptedKey分野を含んでいます。
Pawling Informational [Page 4] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[4ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
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はユニークな創始者UKMが各受取人のためにSKIPJACK CEKを包装するのに使用される各対状KEKを発生させるのに使用される能力を提供します。 ユニークな創始者UKMオプションを使用するとき、各受取人のために別々のRecipientInfo KeyAgreeRecipientInfo構造を構成しなければなりません。 それぞれのKeyAgreeRecipientInfo構造は受取人のために包装されたSKIPJACK CEKを含むただ一つのRecipientEncryptedKey分野を含んでいます。 このオプションは、各受取人のために、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アルゴリズム分野はイド-kEAKeyEncryptionAlgorithm OIDを含まなければなりません。 KeyAgreeRecipientInfo keyEncryptionAlgorithmパラメタ分野は指定されるとしての[CMS]付録A、「ASN.1モジュール」によるKeyWrapAlgorithmを含まなければなりません。 KeyWrapAlgorithmのアルゴリズム分野はFORTEZZAの80ビットの包装機能が80ビットを包装するのに使用されるのを示すイドfortezzaWrap80 OID SKIPJACK CEKであるに違いありません。 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.
創始者が既に明白な受取人でないなら、そして、創始者のために包装されて、EnvelopedDataに含まれていたSKIPJACK CEK SHOULDについてコピーします。 これで、創始者はEnvelopedDataのコンテンツを解読することができます。
4.2.1.1. SKIPJACK CEK Wrap Process Using A Shared Originator UKM Value
4.2.1.1. 共有された創始者UKM価値を使用するトビウオの類CEK包装の過程
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価値が各受取人のためにSKIPJACK CEKを包装するのに使用される各対状KEKを発生させるのに入力としてどう使用されるかを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オプションを使用するとき、同じセットのKEAパラメタを使用することでKEA受取人のすべてのための包装されたSKIPJACK CEKsを含むようにただ一つのRecipientInfo KeyAgreeRecipientInfo構造を構成しなければなりません。 すべての受取人のKEA公開鍵が同じセットのKEAパラメタを使用することで発生したなら、KEA受取人のすべてのためのただ一つのRecipientInfo KeyAgreeRecipientInfo構造があるだけであるに違いありません。 受取人のKEA公開鍵が異なったセットのKEAパラメタを使用することで発生したなら、originatorIdentifierOrKeyがそれぞれの異なったセットの受取人のKEAパラメタにおいて異なるようになるので、複数のRecipientInfo KeyAgreeRecipientInfo分野を構成しなければなりません。
Pawling Informational [Page 5] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[5ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
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 MUSTはそれぞれの異なったセットの受取人のKEAパラメタのために発生しました。 創始者のUKM MUST、各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パラメタは、対状KEKを首尾よく発生させるのにKEAを使用するために同じでなければなりません。 [KEA]はKEA公開鍵がX.509 v3証明書でどう伝えられるかを説明します。 [KEA]は、KEAパラメタがKEA証明書に含まれていないと述べます。 代わりに、あらゆるKEA証明書のsubjectPublicKeyInfoアルゴリズムパラメタ分野で「ドメイン識別子」を供給します。 KEAパラメタが創始者と受取人のものであるなら同じであることを決定するために創始者のところのKEAドメイン識別子と受取人のKEA X.509 v3証明書の値を比較できます。
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 MUSTが創始者のUKMに基づく対状KEKを発生させるのに使用されて、創始者が個人的なKEA主要であり、受取人の128バイトは、公共のKEAキー(受取人のKEA X.509 v3証明書から、得る)とRbが評価するように使用される受取人の128バイトの公共のKEAキーです。
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 MUST、FORTEZZAの80ビットの包装機能に入力されるようにKEAが発生している対状KEKを使用することで、包装されてください。 FORTEZZAの80ビットの包装機能は、16ビットの保全checkvalueに伴う80ビットのSKIPJACK CEKを取って、KEAが発生している対状KEKを使用することで96ビットの結果を生みます。
3) A new RecipientEncryptedKey SEQUENCE MUST be constructed for the
recipient.
3) 受取人のために新しいRecipientEncryptedKey SEQUENCEを組み立てなければなりません。
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であるに違いありません。 期日と他の分野はrecipientEncryptedKeyの排除しているrKeyId SEQUENCEから欠けているに違いありません。
5) The wrapped SKIPJACK CEK MUST be placed in the recipient's
RecipientEncryptedKey encryptedKey OCTET STRING.
5) 置かれたコネが受取人のRecipientEncryptedKey encryptedKey OCTET STRINGであったならSKIPJACK CEK MUSTを包装しました。
6) The recipient's RecipientEncryptedKey MUST be included in the
KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF
RecipientEncryptedKey.
6) KeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKeyに受取人のRecipientEncryptedKeyを含まなければなりません。
Pawling Informational [Page 6] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[6ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
4.2.1.2. SKIPJACK CEK Wrap Process Using Unique Originator UKM Values
4.2.1.2. ユニークな創始者UKM値を使用するトビウオの類CEK包装の過程
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.
このセクションはユニークな創始者UKM価値が各受取人がその受取人の対状KEKを発生させるように入力としてKEAに慣れるようにどう発生するかを説明します。
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 MUSTは発生しました。 創始者のUKM MUST、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 MUSTが創始者のUKMに基づく対状KEKを発生させるのに使用されて、創始者は個人的なKEA主要です、Rbが評価するように公共のKEAキーと受取人の128バイトの公共のKEAキーが使用した受取人128のバイト。
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 MUST、FORTEZZAの80ビットの包装機能に入力されるようにKEAが発生している対状KEKを使用することで、包装されてください。 FORTEZZAの80ビットの包装機能は、16ビットの保全チェック価値に伴う80ビットのSKIPJACK CEKを取って、KEAが発生している対状KEKを使用することで96ビットの結果を生みます。
5) A new RecipientEncryptedKey SEQUENCE MUST be constructed.
5) 新しいRecipientEncryptedKey SEQUENCEを組み立てなければなりません。
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であるに違いありません。 期日と他の分野はRecipientEncryptedKeyの排除しているrKeyId SEQUENCEから欠けているに違いありません。
7) The wrapped SKIPJACK CEK MUST be placed in the
RecipientEncryptedKey encryptedKey OCTET STRING.
7) 置かれたコネがRecipientEncryptedKey encryptedKey OCTET STRINGであったならSKIPJACK CEK MUSTを包装しました。
8) The recipient's RecipientEncryptedKey MUST be the only
RecipientEncryptedKey present in the KeyAgreeRecipientInfo
recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKey.
8) 受取人のRecipientEncryptedKeyはKeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKeyの現在の唯一のRecipientEncryptedKeyであるに違いありません。
9) The RecipientInfo containing the recipient's KeyAgreeRecipientInfo
MUST be included in the EnvelopedData RecipientInfos SET OF
RecipientInfo.
9) EnvelopedData RecipientInfos SET OF RecipientInfoに受取人のKeyAgreeRecipientInfoを含むRecipientInfoを含まなければなりません。
Pawling Informational [Page 7] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[7ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
4.2.2. SKIPJACK CEK Unwrap Process
4.2.2. トビウオの類CEK開けることの過程
This section describes the recipient processing using KEA to generate the SKIPJACK KEK and the subsequent decryption of the SKIPJACK CEK.
このセクションは、SKIPJACK CEKのSKIPJACK KEKとその後の復号化を発生させるのに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オプションをサポートするために、受信ソフトウェアはKeyAgreeRecipientInfo recipientEncryptedKeys SEQUENCE OF RecipientEncryptedKeyで受取人のRecipientEncryptedKeyを捜し求めることができなければなりません。 ユニークなUKMオプションをサポートするために、受信ソフトウェアはEnvelopedData recipientInfos SET OF RecipientInfoで受取人のRecipientEncryptedKeyを捜し求めることができなければなりません、各RecipientInfoがちょうど1RecipientEncryptedKeyを含んでいて。 各RecipientEncryptedKeyに関しては、排除しているrkeyId CHOICEが存在しているなら、受信ソフトウェアは、subjectKeyIdentifier拡張子の値を受取人のKEA X.509 v3証明書からRecipientEncryptedKeyの排除しているrKeyId subjectKeyIdentifier分野に合わせるのを試みなければなりません。 排除しているissuerAndSerialNumber CHOICEが存在しているなら、受信ソフトウェアは、受取人のKEA X.509 v3証明書からの発行人名と通し番号の値をRecipientEncryptedKeyの排除しているissuerAndSerialNumber分野に合わせるのを試みなければなりません。
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 OCTET STRINGから創始者の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 MUSTが創始者のUKMに基づく対状KEKを発生させるのに使用されて、創始者が128バイトの公共のKEA主要であり(創始者のKEA X.509 v3証明書から、抽出されます)、受取人のものは、個人的なKEAキー(RecipientEncryptedKeyの排除している分野によって特定される受取人のKEA X.509 v3証明書に関連している)と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 MUST、開けられた使用がKEAが発生している対状であったなら、FORTEZZAに80ビットで入力されるKEKは機能を開けます。
Pawling Informational [Page 8] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[8ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
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の満足している復号化への入力がEnvelopedData encryptedContentを解読するために処理されるとき、開けることの過程と8バイトのIVがEnvelopedData encryptedContentInfo contentEncryptionAlgorithmパラメタ分野から入手したSKIPJACK CEKから生じる開けられた80ビットのSKIPJACK CEKは使用されています。
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.
このセクションは、左右対称の「以前に、分配された」KEKsを支持するのにCMSのおおわれたデータの満足しているタイプがあるSKIPJACKを使用するためにコンベンションについて説明します。 左右対称の「以前に、分配された」KEKがSKIPJACK CEKを包装するのに使用されると、RecipientInfo KEKRecipientInfo CHOICEを使用しなければなりません。 左右対称の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ビットを包装するのに使用されるのを示すイド-fortezzaWrap80 OID SKIPJACK CEKであるに違いありません。 KEKRecipientInfo keyEncryptionAlgorithmパラメタ分野は欠けているに違いありません。 KEKRecipientInfo encryptedKey分野はFORTEZZAの80ビットの包装機能に入力されるように左右対称の「以前に、分配された」KEKを使用することで包装されたSKIPJACK CEKを含まなければなりません。
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のコード化されたデータの満足しているタイプはコード化された内容にもかかわらず、どんな受取人情報からも成りません。 コード化されたデータのコード化された内容を解読しなければならなかったSKIPJACK CEKを運ぶための方法はこのドキュメントの範囲を超えています。 対応するソフトウェアはコード化されたデータの満足しているタイプを構成するための述べられた[CMS]セクション8、「コード化されたデータの満足しているタイプ」という必要条件を満たさなければなりません。 このセクションが[CMS]テキストを繰り返さないのでこのセクションを読む前に、[CMS]セクション8は研究されるべきです。
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.
[CMS]セクション8によると、EncryptedDataバージョンを設定しなければなりません。
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アルゴリズム分野はイド-fortezzaConfidentialityAlgorithm OIDであるに違いありません。 EncryptedData encryptedContentInfo contentEncryptionAlgorithmパラメタ分野は入力として満足している暗号化の過程に使用される無作為の8バイトのIVを含まなければなりません。
Pawling Informational [Page 9] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[9ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
The EncryptedData unprotectedAttrs MAY be present.
EncryptedData unprotectedAttrsは存在しているかもしれません。
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.
RFC2633[MSG]、セクション2.5.2はSMIMECapabilitiesを定義します。ソフトウェアがSMIMECapabilitiesを発表する場合支持されることができるアルゴリズムの部分的なリストを指定するのに使用されるように属性(SMIMECapability SEQUNCEsのSEQUENCEと定義される)にサインしました。 signedData物を組み立てる対応するソフトウェアがSMIMECapabilitiesを含んだかもしれないら、サインされて、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 MUSTを表すSMIMECapability SEQUENCEはcapabilityID分野にイドkEAKeyEncryptionAlgorithm OIDを含んでいて、パラメタ分野にKeyWrapAlgorithm SEQUENCEを含まなければなりません。 KeyWrapAlgorithmのアルゴリズム分野はイド-fortezzaWrap80 OIDであるに違いありません。 KeyWrapAlgorithmのパラメタ分野は欠けているに違いありません。 SMIMECapability SEQUENCE、KEA SHOULDに関しては、SMIMECapabilitiesリストのかぎ管理アルゴリズム部分で含められてください。 KEA MUSTを表すSMIMECapability SEQUENCEは以下の16進ストリングとしてDERによってコード化されています:
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 MUSTを表すSMIMECapability SEQUENCEはcapabilityID分野にイド-fortezzaConfidentialityAlgorithm OIDを含んでいます、そして、パラメタ分野は欠けているに違いありません。 SMIMECapability SEQUENCE、SKIPJACK SHOULDに関しては、SMIMECapabilitiesリストの左右対称の暗号化アルゴリズム部分で含められてください。 SKIPJACK MUSTを表すSMIMECapability SEQUENCEは以下の16進ストリングとしてDERによってコード化されています:
300b 0609 6086 4801 6502 0101 0400
300b0609 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:
以下のOIDsは[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)}
イド-keyExchangeAlgorithm物の識別子:、:= 共同iso-ccitt(2)国(16)、私たち、(840) 組織(1)gov(101) dod(2) infosec(1)アルゴリズム(1)keyExchangeAlgorithm(22)
Pawling Informational [Page 10] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[10ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
id-fortezzaWrap80 OBJECT IDENTIFIER ::= {joint-iso-ccitt(2)
country(16) us(840) organization(1) gov(101) dod(2) infosec(1)
algorithms(1) fortezzaWrap80Algorithm (23)}
イド-fortezzaWrap80物の識別子:、:= 共同iso-ccitt(2)国(16)、私たち、(840) 組織(1)gov(101) dod(2) infosec(1)アルゴリズム(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)}
イド-kEAKeyEncryptionAlgorithm物の識別子:、:= 共同iso- ccitt(2)国(16)、私たち、(840) 組織(1)gov(101) dod(2) infosec(1)アルゴリズム(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)}
イド-fortezzaConfidentialityAlgorithm物の識別子:、:= 共同iso-ccitt(2)国(16)、私たち、(840) 組織(1)gov(101) dod(2) infosec(1)アルゴリズム(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]で指定されるように、次に、イドfortezzaConfidentialityAlgorithm OIDがAlgorithmIdentifierアルゴリズム分野に存在しているとき、AlgorithmIdentifierパラメタ分野は、存在していなければならなくて、以下の構文を使用することでコード化されたSKIPJACK IV ASN.1を含まなければなりません:
Skipjack-Parm ::= SEQUENCE { initialization-vector OCTET STRING }
トビウオの類-Parm:、:= 系列初期化ベクトル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、「概要」はイドfortezzaConfidentialityAlgorithm OIDとパラメタが現在であるおおわれたデータとコード化されたデータの満足しているタイプを含むCMSの満足しているタイプのためにASN.1コード化コンベンションについて説明します。
References
参照
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、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.
[ケア] Housley、R.とW.ポーク、「インターネットX.509公開鍵暗号基盤証明書における、主要な交換アルゴリズム(ケア)キーの表現」RFC2528(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メッセージ仕様」、RFC2633、1999年6月。
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MUSTSHOULD] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SJ-KEA] SKIPJACK and KEA Algorithm Specifications, Version 2.0,
http://csrc.nist.gov/encryption/skipjack-kea.htm.
[SJ-ケア]のトビウオの類とケアアルゴリズム仕様、バージョン2.0、 http://csrc.nist.gov/encryption/skipjack-kea.htm 。
Pawling Informational [Page 11] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[11ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
[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)合衆国(米国)補足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.
以下の人々はこのメモへの重要な貢献をしました: デヴィッドDalkowski、フィリップ・グリフィン(ラスHousley)はレオンベルガー、金持ちのニコラス、ボブ・レリア、およびジムSchaadを刺します。
Author's Address
作者のアドレス
John Pawling Wang Government Services, Inc. (WGSI), A Getronics Company 141 National Business Pkwy, Suite 210 Annapolis Junction, MD 20701
MD ジョンPawlingワング政府用役Inc.(WGSI)、Getronics会社141の国家のビジネスPkwy、Suite210アナポリス合流点、20701
Phone: (301) 939-2739
(410) 880-6095
EMail: john.pawling@wang.com
以下に電話をしてください。 (301) 939-2739 (410) 880-6095 メールしてください: john.pawling@wang.com
Pawling Informational [Page 12] RFC 2876 KEA and SKIPJACK Algorithms in CMS July 2000
cm2000年7月に情報[12ページ]のRFC2876ケアとトビウオの類アルゴリズムをPawlingします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Pawling Informational [Page 13]
Pawling情報です。[13ページ]
一覧
スポンサーリンク
