RFC3565 日本語訳

Network Working Group                                          J. Schaad
Request for Comments: 3565                       Soaring Hawk Consulting
Category: Standards Track                                      July 2003

Schaadがコメントのために要求するワーキンググループJ.をネットワークでつないでください: カテゴリに相談する3565年の高く昇っているタカ: 標準化過程2003年7月

       Use of the Advanced Encryption Standard (AES) Encryption
            Algorithm in Cryptographic Message Syntax (CMS)

暗号のメッセージ構文におけるエー・イー・エス(AES)暗号化アルゴリズムの使用(cm)

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document specifies the conventions for using the Advanced
   Encryption Standard (AES) algorithm for encryption with the
   Cryptographic Message Syntax (CMS).

このドキュメントはCryptographic Message Syntax(CMS)との暗号化にエー・イー・エス(AES)アルゴリズムを使用するのにコンベンションを指定します。

Conventions used in this document

本書では使用されるコンベンション

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [MUSTSHOULD].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[MUSTSHOULD]で説明されるように本書では解釈されることであるべきです。

1.  Overview

1. 概観

   This document specifies the conventions for using Advanced Encryption
   Standard (AES) content encryption algorithm with the Cryptographic
   Message Syntax [CMS] enveloped-data and encrypted-data content types.

このドキュメントはCryptographic Message Syntax[CMS]のおおわれたデータとコード化されたデータの満足しているタイプでエー・イー・エス(AES)の満足している暗号化アルゴリズムを使用するのにコンベンションを指定します。

   CMS values are generated using ASN.1 [X.208-88], using the Basic
   Encoding Rules (BER) [X.209-88] and the Distinguished Encoding Rules
   (DER) [X.509-88].

CMS値はASN.1[X.208-88]を使用することで発生します、Basic Encoding Rules(BER)[X.209-88]とDistinguished Encoding Rules(DER)[X.509-88]を使用して。

Schaad                      Standards Track                     [Page 1]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[1ページ]。

1.1.  AES

1.1. AES

   The Advanced Encryption Standard (AES) [AES] was developed to replace
   DES [DES].  The AES Federal Information Processing Standard (FIPS)
   Publication specifies a cryptographic algorithm for use by U.S.
   Government organizations.  However, the AES will also be widely used
   by organizations, institutions, and individuals outside of the U.S.
   Government.

エー・イー・エス(AES)[AES]は、DES[DES]を取り替えるために開発されました。 AES連邦情報処理基準(FIPS)公表は米国政府組織による使用のために暗号アルゴリズムを指定します。 しかしながら、また、AESは米国政府の外で組織、団体、および個人によって広く使用されるでしょう。

   Two researchers who developed and submitted the Rijndael algorithm
   for consideration are both cryptographers from Belgium: Dr. Joan
   Daemen of Proton World International and Dr. Vincent Rijmen, a
   postdoctoral researcher in the Electrical Engineering Department of
   Katholieke Universiteit Leuven.

考慮のためのラインダールアルゴリズムを開発して、提出した2人の研究者がベルギーからの両方の暗号使用者です: 国際Proton WorldのジョーンDaemen博士とヴィンセントRijmen博士(Katholieke UniversiteitルーフェンのElectrical技術部の博士号取得後の研究者)。

   The National Institute of Standards and technology (NIST) selected
   the Rijndael algorithm for AES because it offers a combination of
   security, performance, efficiency, ease of implementation, and
   flexibility.  Specifically, Rijndael appears to be consistently a
   very good performer in both hardware and software across a wide range
   of computing environments regardless of its use in feedback or
   non-feedback modes.  Its key setup time is excellent, and its key
   agility is good.  The very low memory requirements of the Rijndael
   algorithm make it very well suited for restricted-space environments,
   in which it also demonstrates excellent performance.  The Rijndael
   algorithm operations are among the easiest to defend against power
   and timing attacks.  Additionally, it appears that some defense can
   be provided against such attacks without significantly impacting the
   algorithm's performance.  Finally, the algorithm's internal round
   structure appears to have good potential to benefit from
   instruction-level parallelism.

セキュリティ、性能、効率、実現の容易さ、および柔軟性の組み合わせを提供するので、Standardsと技術(NIST)のNational InstituteはAESのためにラインダールアルゴリズムを選択しました。 明確に、ラインダールは一貫してフィードバックか非フィードバックモードにおける使用にかかわらずさまざまなコンピューティング環境の向こう側のハードウェアとソフトウェアの両方の非常に良いパフォーマーであるように見えます。 主要な準備時間は素晴らしいです、そして、主要な機敏さは良いです。 ラインダールアルゴリズムの非常に低いメモリ要件は制限領域環境にそれに非常によく合っています。(そこでは、また、それが名演奏を示します)。 ものの中にパワーとタイミング攻撃に対して防御する中で最も簡単なラインダールアルゴリズム操作があります。 さらに、そのような攻撃に対してアルゴリズムの性能にかなり影響を与えないで何らかのディフェンスを提供できるように見えます。 最終的に、アルゴリズムの内部の丸い構造は命令レベル並列度の利益を得る良い可能性を持っているように見えます。

   The AES specifies three key sizes: 128, 192 and 256 bits.

AESは3つの主要なサイズを指定します: 128、192、および256ビット。

2.  Enveloped-data Conventions

2. おおわれたデータコンベンション

   The CMS enveloped-data content type consists of encrypted content and
   wrapped content-encryption keys for one or more recipients.  The AES
   algorithm is used to encrypt the content.

CMSのおおわれたデータの満足しているタイプは1人以上の受取人のためのコード化された内容と包装された満足している暗号化キーから成ります。 AESアルゴリズムは、内容をコード化するのに使用されます。

   Compliant software MUST meet the requirements for constructing an
   enveloped-data content type stated in [CMS] Section 6,
   "Enveloped-data Content Type".

対応するソフトウェアは、[CMS]セクション6に述べられたタイプ、「おおわれたデータの満足しているタイプ」というおおわれたデータ内容を構成するために条件を満たさなければなりません。

   The AES content-encryption key MUST be randomly generated for each
   instance of an enveloped-data content type.  The content-encryption
   key (CEK) is used to encrypt the content.

AES満足している暗号化キーはおおわれたデータの満足しているタイプの各例のために手当たりしだいに発生しなければなりません。 満足している暗号化キー(CEK)は、内容をコード化するのに使用されます。

Schaad                      Standards Track                     [Page 2]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[2ページ]。

   AES can be used with the enveloped-data content type using any of the
   following key management techniques defined in [CMS] Section 6.

[CMS]セクション6で定義された以下のかぎ管理のテクニックのいずれも使用するおおわれたデータの満足しているタイプでAESを使用できます。

   1) Key Transport: The AES CEK is uniquely wrapped for each recipient
   using the recipient's public RSA key and other values.  Section 2.2
   provides additional details.

1) 主要な輸送: AES CEKは、各受取人のために受取人の公共のRSA主要で他の値を使用することで唯一包装されます。 セクション2.2は追加詳細を明らかにします。

   2) Key Agreement: The AES CEK is uniquely wrapped for each recipient
   using a pairwise symmetric key-encryption key (KEK) generated using
   an originator's randomly generated private key (ES-DH [DH]) or
   previously generated private key (SS-DH [DH]), the recipient's public
   DH key, and other values.  Section 2.3 provides additional details.

2) 主要な協定: AES CEKは各受取人のために創始者の手当たりしだいに発生している秘密鍵(ES-DH[DH])か以前に発生している秘密鍵(SS-DH[DH])を使用することで発生する対状の左右対称の主要な暗号化キー(KEK)を使用することで唯一包装されます、受取人の公共のDH主要で、他の値。 セクション2.3は追加詳細を明らかにします。

   3) Previously Distributed Symmetric KEK:  The AES 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 2.4
   provides additional details.

3) 以前に分配された左右対称のKEK: AES CEKは、以前に分配された左右対称のKEK(メールList Keyなどの)を使用することで包装されます。 左右対称のKEKが発生して、分配される方法はこのドキュメントの範囲を超えています。 セクション2.4は追加詳細を明らかにします。

   4) Password Encryption:  The AES CEK is wrapped using a KEK derived
   from a password or other shared secret.  Section 2.5 provides
   additional details.

4) パスワードの暗号化: AES CEKは、パスワードか他の共有秘密キーから得られたKEKを使用することで包装されます。 セクション2.5は追加詳細を明らかにします。

   Documents defining the use of the Other Recipient Info structure will
   need to define the proper use for the AES algorithm if desired.

望まれると、Other Recipient Info構造の使用を定義するドキュメントは、AESアルゴリズムの適切な使用を定義する必要があるでしょう。

2.1.  EnvelopedData Fields

2.1. EnvelopedData分野

   The enveloped-data content type is ASN.1 encoded using the
   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be
   populated as follows:

おおわれたデータの満足しているタイプはEnvelopedData構文を使用することでコード化されたASN.1です。 以下の通りEnvelopedData構文の分野に居住しなければなりません:

   The EnvelopedData version is determined based on a number of factors.

EnvelopedDataバージョンは多くの要因に基づいて決定しています。

   See [CMS] section 6.1 for the algorithm to determine this value.

[CMS]セクション6.1を見て、アルゴリズムはこの値を決定してください。

   The EnvelopedData recipientInfos CHOICE is dependent on the key
   management technique used.  Section 2.2, 2.3, 2.4 and 2.5 provide
   additional information.

EnvelopedData recipientInfos CHOICEはテクニックが使用したかぎ管理に依存しています。 セクション2.2、2.3、2.4、および2.5は追加情報を提供します。

   The EnvelopedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a symmetric encryption algorithm.  Implementations
   MUST support content encryption with AES, but implementations MAY
   support other algorithms as well.

EnvelopedData encryptedContentInfo contentEncryptionAlgorithm分野は左右対称の暗号化アルゴリズムを指定しなければなりません。 実現はAESとの満足している暗号化を支持しなければなりませんが、実現はまた、他のアルゴリズムを支持するかもしれません。

   The EnvelopedData unprotectedAttrs MAY be present.

EnvelopedData unprotectedAttrsは存在しているかもしれません。

Schaad                      Standards Track                     [Page 3]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[3ページ]。

2.2.  KeyTransRecipientInfo Fields

2.2. KeyTransRecipientInfo分野

   The enveloped-data content type is ASN.1 encoded using the
   EnvelopedData syntax.  The fields of the EnvelopedData syntax MUST be
   populated as follows:

おおわれたデータの満足しているタイプはEnvelopedData構文を使用することでコード化されたASN.1です。 以下の通りEnvelopedData構文の分野に居住しなければなりません:

   The KeyTransRecipientInfo version MUST be either 0 or 2.  If the
   RecipientIdentifier is the CHOICE issuerAndSerialNumber, then the
   version MUST be 0.  If the RecipientIdentifier is
   subjectKeyIdentifier, then the version MUST be 2.

KeyTransRecipientInfoバージョンは、0か2であるに違いありません。 RecipientIdentifierがCHOICE issuerAndSerialNumberであるなら、バージョンは0であるに違いありません。 RecipientIdentifierがsubjectKeyIdentifierであるなら、バージョンは2であるに違いありません。

   The KeyTransRecipientInfo RecipientIdentifier provides two
   alternatives for specifying the recipient's certificate, and thereby
   the recipient's public key.  The recipient's certificate MUST contain
   a RSA public key.  The CEK is encrypted with the recipient's RSA
   public key.  The issuerAndSerialNumber alternative identifies the
   recipient's certificate by the issuer's distinguished name and the
   certificate serial number; the subjectKeyIdentifier identifies the
   recipient's certificate by the X.509 subjectKeyIdentifier extension
   value.

KeyTransRecipientInfo RecipientIdentifierは受取人の証明書を指定するための2つの選択肢を提供して、その結果、受取人の公開鍵を提供します。 受取人の証明書はRSA公開鍵を含まなければなりません。 CEKは受取人のRSA公開鍵でコード化されます。 issuerAndSerialNumber代替手段は発行人の分類名と証明書通し番号で受取人の証明書を特定します。 subjectKeyIdentifierはX.509 subjectKeyIdentifier拡大価値で受取人の証明書を特定します。

   The KeyTransRecipientInfo keyEncryptionAlgorithm field specifies the
   key transport algorithm (i.e., RSAES-OAEP [RSA-OAEP]), and the
   associated parameters used to encrypt the CEK for the recipient.

KeyTransRecipientInfo keyEncryptionAlgorithm分野は主要な輸送アルゴリズム(すなわち、RSAES-OAEP[RSA-OAEP])、および受取人のためにCEKをコード化するのに使用される関連パラメタを指定します。

   The KeyTransRecipientInfo encryptedKey is the result of encrypting
   the CEK with the recipient's RSA public key.

KeyTransRecipientInfo encryptedKeyは受取人のRSA公開鍵でCEKをコード化するという結果です。

2.3.  KeyAgreeRecipientInfo Fields

2.3. KeyAgreeRecipientInfo分野

   This section describes the conventions for using ES-DH or SS-DH and
   AES with the CMS enveloped-data content type to support key
   agreement.  When key agreement is used, then the RecipientInfo
   keyAgreeRecipientInfo CHOICE MUST be used.

このセクションがES-DHを使用するためにコンベンションについて説明するか、またはCMSおおわれたデータ内容があるSS-DHとAESは、主要な協定をサポートするためにタイプします。 主要な協定が使用されていると、RecipientInfo keyAgreeRecipientInfo CHOICEを使用しなければなりません。

   The KeyAgreeRecipient version MUST be 3.

KeyAgreeRecipientバージョンは3であるに違いありません。

   The EnvelopedData originatorInfo field MUST be the originatorKey
   alternative.  The originatorKey algorithm fields MUST contain the
   dh-public-number object identifier with absent parameters.  The
   originatorKey publicKey MUST contain the originator's ephemeral
   public key.

EnvelopedData originatorInfo分野はoriginatorKey代替手段であるに違いありません。 originatorKeyアルゴリズム分野は欠けているパラメタがあるdhの公共の番号物の識別子を含まなければなりません。 originatorKey publicKeyは創始者のはかない公開鍵を含まなければなりません。

   The EnvelopedData ukm MAY be present.

EnvelopedData ukmは存在しているかもしれません。

   The EnvelopedData keyEncrytionAlgorithm MUST be the id-alg-ESDH
   algorithm identifier [CMSALG].

EnvelopedData keyEncrytionAlgorithmはイド-alg-ESDHアルゴリズム識別子であるに違いありません[CMSALG]。

Schaad                      Standards Track                     [Page 4]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[4ページ]。

2.3.1.  ES-DH/AES Key Derivation

2.3.1. ES-DH/AESの主要な派生

   Generation of the AES KEK to be used with the AES-key wrap algorithm
   is done using the method described in [DH].

AES主要な包装アルゴリズムで使用されるべきAES KEKの世代は[DH]で説明された方法を使用し終わっています。

2.3.1.1.  Example 1

2.3.1.1. 例1

   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

ZZは20バイト00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13です。

   The key wrap algorithm is AES-128 wrap, so we need 128 bits (16
   bytes) of keying material.

主要な包装アルゴリズムがAES-128包装であるので、私たちは合わせることの材料の128個のかけら(16バイト)を必要とします。

   No partyAInfo is used.

どんなpartyAInfoも使用されていません。

   Consequently, the input to SHA-1 is:

その結果、SHA-1への入力は以下の通りです。

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
   30 1b
      30 11
         06 09 60 86 48 01 65 03 04 01 05           ; AES-128 wrap OID
         04 04
            00 00 00 01                             ; Counter
      a2 06
         04 04
         00 00 00 80                                ; key length

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ30 1b30 11 06 09 60 86 48 01 65 03 04 01 05。 AES-128はOID04 04 00 00 00 01を包装します。 a2 06 04 04 00 00 00 80を打ち返してください。 キー長

   And the output is the 32 bytes:

そして、出力は32バイトです:

   d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64 49 08 50 f9

d6 d6 b0 94c1 02 7a 7d e6 e3 11 72 94a3 53 64 49 08 50f9

   Consequently,

その結果

   K= d6 d6 b0 94 c1 02 7a 7d e6 e3 11 72 94 a3 53 64

Kはd6 d6 b0 94c1 02 7a 7d e6 e3 11 72 94a3 53 64と等しいです。

Schaad                      Standards Track                     [Page 5]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[5ページ]。

2.3.1.2.  Example 2

2.3.1.2. 例2

   ZZ is the 20 bytes 00 01 02 03 04 05 06 07 08 09
                      0a 0b 0c 0d 0e 0f 10 11 12 13

ZZは20バイト00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13です。

   The key wrap algorithm is AES-256 key wrap, so we need 256 bits (32
   bytes) of keying material.

主要な包装アルゴリズムがAES-256の主要な包装であるので、私たちは合わせることの材料の256個のかけら(32バイト)を必要とします。

   The partyAInfo used is the 64 bytes

使用されるpartyAInfoは64バイトです。

   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
   01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01

01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01

   Consequently, the input to first invocation of SHA-1 is:

その結果、最初に、SHA-1の実施への入力は以下の通りです。

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
   30 5f
      30 11
         06 09 60 86 48 01 65 03 04 01 2d            ; AES-256 wrap OID
         04 04
            00 00 00 01                              ; Counter
      a0 42
         04 40
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ30 5f30 11 06 09 60 86 48 01 65 03 04 01 2d。 AES-256はOID04 04 00 00 00 01を包装します。 a0 42 04 40 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01を打ち返してください。 partyAInfo

            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
      a2 06
         04 04
            00 00 01 00                              ; key length

01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01a2 06 04 04 00 00 01 00。 キー長

   And the output is the 20 bytes:

そして、出力は20バイトです:

   88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B 32 30 D8 93

88 90 58 5C4 28Eの1A5C11 67カリフォルニアA5 30、D5 9B32 30D8 93になってください。

Schaad                      Standards Track                     [Page 6]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[6ページ]。

   The input to second invocation of SHA-1 is:

SHA-1の2番目の実施への入力は以下の通りです。

   00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 ; ZZ
   30 5f
      30 11
         06 09 60 86 48 01 65 03 04 01 2d            ; AES-256 wrap OID
         04 04
            00 00 00 02                              ; Counter
      a0 42
         04 40
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01 ; partyAInfo

00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f10 11 12 13。 ZZ30 5f30 11 06 09 60 86 48 01 65 03 04 01 2d。 AES-256はOID04 04 00 00 00 02を包装します。 a0 42 04 40 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01を打ち返してください。 partyAInfo

            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
            01 23 45 67 89 ab cd ef fe dc ba 98 76 54 32 01
      a2 06
         04 04
            00 00 01 00                              ; key length

01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01 01 23 45 67 89腹筋cd ef fe dc Ba98 76 54 32 01a2 06 04 04 00 00 01 00。 キー長

   And the output is the 20 bytes:

そして、出力は20バイトです:

   CB A8 F9 22 BD 1B 56 A0 71 C9 6F 90 36 C6 04 2C AA 20 94 37

CB A8 F9 22BD 1B56A0 71C9 6F90 36C6 04 2C AA20 94 37

   Consequently,

その結果

   K = 88 90 58 5C 4E 28 1A 5C 11 67 CA A5 30 BE D5 9B
       32 30 D8 93 CB A8 F9 22 BD 1B 56 A0

KはD5 9B32 30がD8 93CB A8 F9 22BD 1B56A0であったなら88 90 58 5C4 28Eの1A5C11 67カリフォルニアA5 30と等しいです。

2.3.2.  AES CEK Wrap Process

2.3.2. AES CEK包装の過程

   The AES key wrap algorithm encrypts one AES key in another AES key.
   The algorithm produces an output 64-bits longer than the input AES
   CEK, the additional bits are a checksum.  The algorithm uses 6*n AES
   encryption/decryption operations where n is number of 64-bit blocks
   in the AES CEK.  Full details of the AES key wrap algorithm are
   available at [AES-WRAP].

AESの主要な包装アルゴリズムは別のAESキーで主要な1AESをコード化します。 アルゴリズムは入力AES CEKより64ビット長い出力を起こして、追加ビットはチェックサムです。 アルゴリズムはnがAES CEKの64ビットのブロックの数であるところで6*n AES暗号化/復号化操作を使用します。 AESの主要な包装アルゴリズムの一部始終は[AES-WRAP]で利用可能です。

   NIST has assigned the following OIDs to define the AES key wrap
   algorithm.

NISTは、AESの主要な包装アルゴリズムを定義するために以下のOIDsを割り当てました。

        id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
        id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
        id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

イドaes128包装OBJECT IDENTIFIER:、:= aes5イドaes192包装OBJECT IDENTIFIER:、:= aes25イドaes256包装OBJECT IDENTIFIER:、:= aes45

   In all cases the parameters field MUST be absent.  The OID gives the
   KEK key size, but does not make any statements as to the size of the
   wrapped AES CEK.  Implementations MAY use different KEK and CEK

パラメタがさばくケースは全部で、欠けていなければなりません。 OIDはKEKの主要なサイズを与えますが、包装されたAES CEKのサイズに関して少しの声明も出しません。 実現は異なったKEKとCEKを使用するかもしれません。

Schaad                      Standards Track                     [Page 7]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[7ページ]。

   sizes.  Implements MUST support the CEK and the KEK having the same
   length.  If different lengths are supported, the KEK MUST be of equal
   or greater length than the CEK.

サイズ。 道具は同じ長さを持っているCEKとKEKを支持しなければなりません。 異なった長さが支持されるなら、KEK MUSTはCEKより等しいか大きい長さについて支持されます。

2.4.  KEKRecipientInfo Fields

2.4. KEKRecipientInfo分野

   This section describes the conventions for using AES with the CMS
   enveloped-data content type to support previously distributed
   symmetric KEKs.  When a previously distributed symmetric KEK is used
   to wrap the AES 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.  One possible
   method of distributing keys is documented in [SYMKEYDIST].

このセクションは、以前に分配された左右対称のKEKsを支持するのにCMSのおおわれたデータの満足しているタイプがあるAESを使用するためにコンベンションについて説明します。 以前に分配された左右対称のKEKがAES CEKを包装するのに使用されると、RecipientInfo KEKRecipientInfo CHOICEを使用しなければなりません。 左右対称のKEKを発生して、分配するのに使用される方法はこのドキュメントの範囲を超えています。 キーを分配する1つの可能な方法が[SYMKEYDIST]に記録されます。

   The KEKRecipientInfo fields MUST be populated as specified in [CMS]
   Section 6.2.3, KEKRecipientInfo Type.

KEKRecipientInfo Type、分野に居住しなければならないKEKRecipientInfoは[CMS]セクション6.2.3で指定しました。

   The KEKRecipientInfo keyEncryptionAlgorithm algorithm field MUST be
   one of the OIDs defined in section 2.3.2 indicating that the AES wrap
   function is used to wrap the AES CEK.  The KEKRecipientInfo
   keyEncryptionAlgorithm parameters field MUST be absent.

KEKRecipientInfo keyEncryptionAlgorithmアルゴリズム分野はAES包装機能がAES CEKを包装するのに使用されるのを示すセクション2.3.2で定義されたOIDsの1つであるに違いありません。 KEKRecipientInfo keyEncryptionAlgorithmパラメタ分野は欠けているに違いありません。

   The KEKRecipientInfo encryptedKey field MUST include the AES CEK
   wrapped using the previously distributed symmetric KEK as input to
   the AES wrap function.

KEKRecipientInfo encryptedKey分野はAES包装機能に入力されるように以前に分配された左右対称のKEKを使用することで包装されたAES CEKを含まなければなりません。

2.5.  PasswordRecipientInfo Fields

2.5. PasswordRecipientInfo分野

   This section describes the conventions for using AES with the CMS
   enveloped-data content type to support password-based key management.

このセクションは、パスワードを拠点とするかぎ管理を支持するのにCMSのおおわれたデータの満足しているタイプがあるAESを使用するためにコンベンションについて説明します。

   When a password derived KEK is used to wrap the AES CEK, then the
   RecipientInfo PasswordRecipientInfo CHOICE MUST be used.

パスワードがいつKEKを引き出したかはAES CEKを包装するのに使用されて、次に、RecipientInfo PasswordRecipientInfo CHOICEを使用しなければなりません。

   The keyEncryptionAlgorithm algorithm field MUST be one of the OIDs
   defined in section 2.3.2 indicating the AES wrap function is used to
   wrap the AES CEK.  The keyEncryptionAlgorithm parameters field MUST
   be absent.

keyEncryptionAlgorithmアルゴリズム分野はAES包装機能がAES CEKを包装するのに使用されるのを示すセクション2.3.2で定義されたOIDsの1つであるに違いありません。 keyEncryptionAlgorithmパラメタ分野は欠けているに違いありません。

   The encryptedKey field MUST be the result of the AES key wrap
   algorithm applied to the AES CEK value.

encryptedKey分野はAES CEK値に適用されたAESの主要な包装アルゴリズムの結果であるに違いありません。

3.  Encrypted-data Conventions

3. コード化されたデータコンベンション

   The CMS encrypted-data content type consists of encrypted content
   with implicit key management.  The AES algorithm is used to encrypt
   the content.

CMSのコード化されたデータの満足しているタイプはコード化された内容から内在しているかぎ管理で成ります。 AESアルゴリズムは、内容をコード化するのに使用されます。

Schaad                      Standards Track                     [Page 8]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[8ページ]。

   Compliant software MUST meet the requirements for constructing an
   enveloped-data content type stated in [CMS] Section 8,
   "Encrypted-data Content Type".

対応するソフトウェアは、[CMS]セクション8に述べられたタイプ、「コード化されたデータの満足しているタイプ」というおおわれたデータ内容を構成するために条件を満たさなければなりません。

   The encrypted-data content type is ASN.1 encoded using the
   EncryptededData syntax.  The fields of the EncryptedData syntax MUST
   be populated as follows:

コード化されたデータの満足しているタイプはEncryptededData構文を使用することでコード化されたASN.1です。 以下の通りEncryptedData構文の分野に居住しなければなりません:

   The EncryptedData version is determined based on a number of factors.

EncryptedDataバージョンは多くの要因に基づいて決定しています。

   See [CMS] section 9.1 for the algorithm to determine this value.

[CMS]セクション9.1を見て、アルゴリズムはこの値を決定してください。

   The EncryptedData encryptedContentInfo contentEncryptionAlgorithm
   field MUST specify a symmetric encryption algorithm.  Implementations
   MUST support encryption using AES, but implementations MAY support
   other algorithms as well.

EncryptedData encryptedContentInfo contentEncryptionAlgorithm分野は左右対称の暗号化アルゴリズムを指定しなければなりません。 AESを使用して、実現は暗号化を支持しなければなりませんが、実現はまた、他のアルゴリズムを支持するかもしれません。

   The EncryptedData unprotectedAttrs MAY be present.

EncryptedData unprotectedAttrsは存在しているかもしれません。

4.  Algorithm Identifiers and Parameters

4. アルゴリズム識別子とパラメタ

   This section specified algorithm identifiers for the AES encryption
   algorithm.

このセクションはAES暗号化アルゴリズムのためのアルゴリズム識別子を指定しました。

4.1.  AES Algorithm Identifiers and Parameters

4.1. AESアルゴリズム識別子とパラメタ

   The AES algorithm is defined in [AES].  RSAES-OAEP [RSA-OAEP] MAY be
   used to transport AES keys.

AESアルゴリズムは[AES]で定義されます。 RSAES-OAEP[RSA-OAEP]は、AESキーを輸送するのに使用されるかもしれません。

   AES is added to the set of symmetric content encryption algorithms
   defined in [CMSALG].  The AES content-encryption algorithm, in Cipher
   Block Chaining (CBC) mode, for the three different key sizes are
   identified by the following object identifiers:

AESは[CMSALG]で定義された左右対称の満足している暗号化アルゴリズムのセットに追加されます。 AES満足している暗号化アルゴリズム、Cipher Block Chaining(CBC)モードで、3において、異なった主要なサイズは以下の物の識別子によって特定されます:

       id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
       id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
       id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }

イド-aes128-CBC物の識別子:、:= aes2イド-aes192-CBC OBJECT IDENTIFIER:、:= aes22イド-aes256-CBC OBJECT IDENTIFIER:、:= aes42

   The AlgorithmIdentifier parameters field MUST be present, and the
   parameters field MUST contain a AES-IV:

AlgorithmIdentifierパラメタ分野は存在していなければなりません、そして、パラメタ分野はAES-IVを含まなければなりません:

       AES-IV ::= OCTET STRING (SIZE(16))

AES-IV:、:= 八重奏ストリング(サイズ(16))

   Content encryption algorithm identifiers are located in the
   EnvelopedData EncryptedContentInfo contentEncryptionAlgorithm and the
   EncryptedData EncryptedContentInfo contentEncryptionAlgorithm fields.

満足している暗号化アルゴリズム識別子はEnvelopedData EncryptedContentInfo contentEncryptionAlgorithmとEncryptedData EncryptedContentInfo contentEncryptionAlgorithm分野に位置しています。

Schaad                      Standards Track                     [Page 9]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[9ページ]。

   Content encryption algorithms are used to encrypt the content located
   in the EnvelopedData EncryptedContentInfo encryptedContent and the
   EncryptedData EncryptedContentInfo encryptedContent fields.

満足している暗号化アルゴリズムは、EnvelopedData EncryptedContentInfo encryptedContentに位置する内容とEncryptedData EncryptedContentInfo encryptedContent分野をコード化するのに使用されます。

5.  SMIMECapabilities Attribute Conventions

5. SMIMECapabilities属性コンベンション

   An S/MIME client SHOULD announce the set of cryptographic functions
   it supports by using the S/MIME capabilities attribute.  This
   attribute provides a partial list of object identifiers of
   cryptographic functions and MUST be signed by the client.  The
   algorithm OIDs SHOULD be logically separated in functional categories
   and MUST be ordered with respect to their preference.

SHOULDがS/MIME能力属性を使用することでそれがサポートする暗号の機能のセットを発表するS/MIMEクライアント。 この属性を暗号の機能に関する物の識別子の部分的なリストを提供して、クライアントはサインしなければなりません。 アルゴリズムOIDs SHOULDを機能的なカテゴリで論理的に切り離して、彼らの好みに関して注文しなければなりません。

   RFC 2633 [MSG], Section 2.5.2 defines the SMIMECapabilities signed
   attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs) to be
   used to specify a partial list of algorithms that the software
   announcing the SMIMECapabilities can support.

RFC2633[MSG]、セクション2.5.2はSMIMECapabilitiesを定義します。ソフトウェアがSMIMECapabilitiesを発表する場合支持されることができるアルゴリズムの部分的なリストを指定するのに使用されるように属性(SMIMECapability SEQUENCEsのSEQUENCEと定義される)にサインしました。

5.1.  AES S/MIME Capability Attributes

5.1. AES S/MIME能力属性

   If an S/MIME client is required to support symmetric encryption with
   AES, the capabilities attribute MUST contain the AES object
   identifier specified above in the category of symmetric algorithms.
   The parameter with this encoding MUST be absent.

S/MIMEクライアントがAESとの左右対称の暗号化を支持するのに必要であるなら、能力属性は上で左右対称のアルゴリズムのカテゴリで指定されたAES物の識別子を含まなければなりません。このコード化があるパラメタは欠けているに違いありません。

   The encodings for the mandatory key sizes are:

義務的な主要なサイズのためのencodingsは以下の通りです。

         Key Size                   Capability
          128          30 0B 06 09 60 86 48 01 65 03 04 01 02
          196          30 0B 06 09 60 86 48 01 65 03 04 01 16
          256          30 0B 06 09 60 86 48 01 65 03 04 01 2A

主要なサイズ能力128 30 0B06 09 60 86 48 01 65 03 04 01 02 196 30 0B06 09 60 86 48 01 65 03 04 01 16 256 30 0B06 09 60 86 48 01 65 03 04 01 2A

   When a sending agent creates an encrypted message, it has to decide
   which type of encryption algorithm to use.  In general the decision
   process involves information obtained from the capabilities lists
   included in messages received from the recipient, as well as other
   information such as private agreements, user preferences, legal
   restrictions, and so on.  If users require AES for symmetric
   encryption, the S/MIME clients on both the sending and receiving side
   MUST support it, and it MUST be set in the user preferences.

送付エージェントが暗号化メッセージを作成するとき、それは、どのタイプの暗号化アルゴリズムを使用するかを決めなければなりません。 一般に、決定の過程は、リストを含んでいて、能力から得られた情報に受取人から受け取られたメッセージにかかわって、個人的な協定、ユーザー選択、法的規制などなどのように他の情報にかかわります。 ユーザが左右対称の暗号化のためにAESを必要とするなら、発信と受信の両方のクライアントは面があるS/MIMEがそれを支持しなければなりません、そして、ユーザー選択でそれを設定しなければなりません。

Schaad                      Standards Track                    [Page 10]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[10ページ]。

6.  Security Considerations

6. セキュリティ問題

   If RSA-OAEP [PKCS#1v2.0] and RSA PKCS #1 v1.5 [PKCS#1v1.5] are both
   used to transport the same CEK, then an attacker can still use the
   Bleichenbacher attack against the RSA PKCS #1 v1.5 encrypted key.  It
   is generally unadvisable to mix both RSA-OAEP and RSA PKCS#1 v1.5 in
   the same set of recipients.

RSA-OAEP[PKCS#1v2.0]とRSA PKCS#1v1.5[PKCS#1v1.5]が同じCEKを輸送するのにともに使用されるなら、攻撃者はまだ主要な状態でコード化されたRSA PKCS#1v1.5に対してBleichenbacher攻撃を使用できます。 一般に、同じセットの受取人でRSA-OAEPとRSA PKCS#1v1.5の両方を混合するのは賢明ではありません。

   Implementations must protect the RSA private key and the CEK.
   Compromise of the RSA private key may result in the disclosure of all
   messages protected with that key.  Compromise of the CEK may result
   in disclosure of the associated encrypted content.

実現はRSA秘密鍵とCEKを保護しなければなりません。 RSA秘密鍵の妥協はそのキーで保護されたすべてのメッセージの公開をもたらすかもしれません。 CEKの妥協は関連コード化された内容の公開をもたらすかもしれません。

   The generation of AES CEKs relies on random numbers.  The use of
   inadequate pseudo-random number generators (PRNGs) to generate these
   values can result in little or no security.  An attacker may find it
   much easier to reproduce the PRNG environment that produced the keys,
   searching the resulting small set of possibilities, rather than brute
   force searching the whole key space.  The generation of quality
   random numbers is difficult.  RFC 1750 [RANDOM] offers important
   guidance in this area.

AES CEKsの世代は乱数を当てにします。 これらの値を発生させる不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、キーを生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、全体の主要なスペースを捜す馬鹿力よりむしろ結果として起こる小さい可能性を捜して。 上質の乱数の世代は難しいです。 RFC1750[RANDOM]はこの領域で重要な指導を提供します。

   When wrapping a CEK with a KEK, the KEK MUST always be at least the
   same length as the CEK.  An attacker will generally work at the
   weakest point in an encryption system.  This would be the smaller of
   the two key sizes for a brute force attack.

いつがKEKと共にCEKを包装して、KEK MUSTは少なくともいつも包装します。CEKと同じ長さ。 一般に、攻撃者は暗号化システムで最も弱いポイントで働くでしょう。 総当たり攻撃には、2つの主要なサイズがこれは、より小さいでしょう。

Normative References

引用規格

   [AES]         National Institute of Standards.  FIPS Pub 197:
                 Advanced Encryption Standard (AES).  26 November 2001.

規格の[AES]国家の研究所。 FIPSパブ197: エー・イー・エス(AES)。 2001年11月26日。

   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                 3369, August 2002.

[cm] Housley、R.、「暗号のメッセージ構文(cm)」、RFC3369、2002年8月。

   [AES-WRAP]    Schaad, J. and R. Housley, "Advanced Encryption
                 Standard (AES) Key Wrap Algorithm", RFC 3394, September
                 2002.

[AES-包装] SchaadとJ.とR.Housley、「エー・イー・エス(AES)の主要な包装アルゴリズム」、RFC3394、2002年9月。

   [CMSALG]      Housley, R., "Cryptographic Message Syntax (CMS)
                 Algorithms, RFC 3370, August 2002.

[CMSALG] Housley、R.、「暗号のメッセージ構文(cm)アルゴリズム、RFC3370、2002年8月。」

   [DES]         National Institute of Standards and Technology. FIPS
                 Pub 46: Data Encryption Standard.  15 January 1977.

[DES]米国商務省標準技術局。 FIPSパブ46: データ暗号化規格。 1977年1月15日。

   [DH]          Rescorla, E., "Diffie-Hellman Key Agreement Method",
                 RFC 2631, June 1999.

[DH] レスコラ、E.、「ディフィー-ヘルマンの主要な協定方法」、RFC2631、1999年6月。

Schaad                      Standards Track                    [Page 11]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[11ページ]。

   [MUSTSHOULD]  Bradner, S., "Key Words for Use in RFCs to Indicate
                 Requirement Levels", BCP 14, RFC 2119, March 1997.

[MUSTSHOULD] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

   [RSA-OAEP]    Housley, R. "Use of the RSAES-OAEP Key Transport
                 Algorithm in the Cryptographic Message Syntax (CMS)",
                 RFC 3560, July 2003.

[RSA-OAEP]Housley、R. 「暗号のメッセージ構文(cm)におけるRSAES-OAEPの主要な輸送アルゴリズムの使用」、RFC3560、2003年7月。

   [X.208-88]    CCITT.  Recommendation X.208: Specification of Abstract
                 Syntax Notation One (ASN.1).  1988.

[X.208-88]CCITT。 推薦X.208: 抽象構文記法1(ASN.1)の仕様。 1988.

   [X.209-88]    CCITT.  Recommendation X.209: Specification of Basic
                 Encoding Rules for Abstract Syntax Notation One
                 (ASN.1). 1988.

[X.209-88]CCITT。 推薦X.209: 基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治されます。 1988.

   [X.509-88]    CCITT.  Recommendation X.509: The Directory -
                 Authentication Framework.  1988.

[X.509-88]CCITT。 推薦X.509: ディレクトリ--認証枠組み。 1988.

Informational References

情報の参照

   [MSG]         Ramsdell, B., Editor, "S/MIME Version 3 Message
                 Specification", RFC 2633, June 1999.

[MSG] Ramsdell、B.、エディタ、「S/MIMEバージョン3メッセージ仕様」、RFC2633、1999年6月。

   [PKCS#1v1.5]  Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5",
                 RFC 2313, March 1998.

[PKCS#1v1.5]Kaliski、B.、「PKCS#1:」 RSA暗号化、バージョン1.5インチ、RFC2313、1998年3月。

   [PKCS#1v2.0]  Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
                 RFC 2437, October 1998.

[PKCS#1v2.0]Kaliski、B.、「PKCS#1:」 RSA暗号化、バージョン2インチ、RFC2437、1998年10月。

   [RANDOM]      Eastlake, D., Crocker, S. and J. Schiller, "Randomness
                 Recommendations for Security", RFC 1750, December 1994.

[無作為の] イーストレークとD.とクロッカーとS.とJ.シラー、「セキュリティのための偶発性推薦」、RFC1750、1994年12月。

   [SYMKEYDIST]  Turner, S., "CMS Symmetric Key Management and
                 Distribution", Work in Progress, January 2003.

[SYMKEYDIST] ターナーと、S.と、「cm対称鍵管理と分配」は進歩、2003年1月に働いています。

Acknowledgements

承認

   This document is the result of contributions from many professionals.
   We appreciate the hard work of all members of the IETF S/MIME Working
   Group.

このドキュメントは多くの専門家からの貢献の結果です。 私たちはIETF S/MIME作業部会のすべてのメンバーのきつい仕事に感謝します。

Schaad                      Standards Track                    [Page 12]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[12ページ]。

Appendix A  ASN.1 Module

付録はASN.1モジュールです。

CMSAesRsaesOaep {iso(1) member-body(2) us(840) rsadsi(113549)
      pkcs(1) pkcs-9(9) smime(16) modules(0) id-mod-cms-aes(19) }

CMSAesRsaesOaepiso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)、イドモッズcm aes(19)

DEFINITIONS IMPLICIT TAGS ::=
BEGIN

定義、内在しているタグ:、:= 始まってください。

-- EXPORTS ALL --
IMPORTS
    -- PKIX
      AlgorithmIdentifier
          FROM PKIXExplicit88 {iso(1) identified-organization(3) dod(6)
              internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
              id-pkix1-explicit(18)};

-- EXPORTS ALL--IMPORTS--PKIX AlgorithmIdentifier FROM PKIXExplicit88のiso(1)の特定されて組織(3)dod(6)インターネット(1)セキュリティ(5)メカニズム(5)pkix(7)イドモッズ(0)イド-pkix1明白な(18)。

-- AES information object identifiers --

-- AES情報物の識別子--

aes OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840)
               organization(1) gov(101) csor(3)_ nistAlgorithms(4)  1 }

aes OBJECT IDENTIFIER:、:= 共同iso-itu t(2)国、(16) 私たち(840)組織(1)gov(101) csor(3)_nistAlgorithms(4)1

-- AES using CBC-chaining mode for key sizes of 128, 192, 256

-- 128、192、256の主要なサイズにCBC-推論モードを使用するAES

id-aes128-CBC OBJECT IDENTIFIER ::= { aes 2 }
id-aes192-CBC OBJECT IDENTIFIER ::= { aes 22 }
id-aes256-CBC OBJECT IDENTIFIER ::= { aes 42 }

イド-aes128-CBC物の識別子:、:= aes2イド-aes192-CBC OBJECT IDENTIFIER:、:= aes22イド-aes256-CBC OBJECT IDENTIFIER:、:= aes42

-- AES-IV is a the parameter for all the above object identifiers.

-- AES-IVはaです。すべての上記の物の識別子のためのパラメタ。

AES-IV ::= OCTET STRING (SIZE(16))

AES-IV:、:= 八重奏ストリング(サイズ(16))

-- AES Key Wrap Algorithm Identifiers  - Parameter is absent

-- AES Key Wrap Algorithm Identifiers--パラメタは欠けています。

id-aes128-wrap OBJECT IDENTIFIER ::= { aes 5 }
id-aes192-wrap OBJECT IDENTIFIER ::= { aes 25 }
id-aes256-wrap OBJECT IDENTIFIER ::= { aes 45 }

イドaes128包装OBJECT IDENTIFIER:、:= aes5イドaes192包装OBJECT IDENTIFIER:、:= aes25イドaes256包装OBJECT IDENTIFIER:、:= aes45

END

終わり

Author's Address

作者のアドレス

   Jim Schaad
   Soaring Hawk Consulting

ジムSchaad Soaringはコンサルティングを襲います。

   EMail: jimsch@exmsft.com

メール: jimsch@exmsft.com

Schaad                      Standards Track                    [Page 13]

RFC 3565       Use of the AES Encryption Algorithm in CMS      July 2003

Schaad規格はcm2003年7月にAES暗号化アルゴリズムのRFC3565使用を追跡します[13ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 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 assignees.

上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Schaad                      Standards Track                    [Page 14]

Schaad標準化過程[14ページ]