RFC5083 日本語訳

Network Working Group                                        R. Housley
Request for Comments: 5083                               Vigil Security
Updates: 3852                                             November 2007
Category: Standards Track

Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5083の不寝番セキュリティアップデート: 3852 2007年11月のカテゴリ: 標準化過程

                   Cryptographic Message Syntax (CMS)
               Authenticated-Enveloped-Data Content Type

暗号のメッセージ構文(cm)認証されたおおわれたデータcontent type

Status of This Memo

このメモの状態

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

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

Abstract

要約

   This document describes an additional content type for the
   Cryptographic Message Syntax (CMS).  The authenticated-enveloped-data
   content type is intended for use with authenticated encryption modes.
   All of the various key management techniques that are supported in
   the CMS enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

このドキュメントはCryptographic Message Syntax(CMS)のために追加content typeについて説明します。 認証されたおおわれたデータcontent typeは認証された暗号化モードがある使用のために意図します。 また、CMSおおわれたデータcontent typeでサポートされる様々なかぎ管理のテクニックのすべてがCMS認証されたおおわれたデータcontent typeによってサポートされます。

1. Introduction

1. 序論

   This document describes an additional content type for the
   Cryptographic Message Syntax (CMS) [CMS].  The authenticated-
   enveloped-data content type is intended for use with authenticated
   encryption modes, where an arbitrary content is both authenticated
   and encrypted.  Also, some associated data in the form of
   authenticated attributes can also be authenticated.  All of the
   various key management techniques that are supported in the CMS
   enveloped-data content type are also supported by the CMS
   authenticated-enveloped-data content type.

このドキュメントはCryptographic Message Syntax(CMS)[CMS]のために追加content typeについて説明します。 認証されたおおわれたデータcontent typeは使用のために認証された暗号化モードで意図します。そこでは、任意の内容は、認証されて、暗号化されます。 また、また、認証された属性の形のいくつかの関連データを認証できます。 また、CMSおおわれたデータcontent typeでサポートされる様々なかぎ管理のテクニックのすべてがCMS認証されたおおわれたデータcontent typeによってサポートされます。

   The conventions for using the Advanced Encryption Standard-Counter
   with Cipher Block Chaining-Message Authentication Code (AES-CCM) and
   the AES-Galois/Counter Mode (GCM) authenticated encryption algorithms
   with the CMS authenticated-enveloped-data content type defined in
   this document can be found in [AESALGS].

Cipher Block Chaining-メッセージ立証コード(AES-CCM)があるAdvanced Encryption Standard-カウンタとAES-ガロア/カウンタMode(GCM)を使用するとCMS認証されたおおわれたデータcontent typeが定義されている状態で暗号化アルゴリズムが認証されたので、[AESALGS]で本書ではコンベンションを見つけることができます。

   The authenticated-enveloped-data content type, like all of the other
   CMS content types, employs ASN.1 [X.208-88], and it uses both the
   Basic Encoding Rules (BER) [X.209-88] and the Distinguished Encoding
   Rules (DER) [X.509-88].

他のCMS content type、雇用ASN.1[X.208-88]、およびそれのすべてのような認証されたおおわれたデータcontent typeはBasic Encoding Rules(BER)[X.209-88]とDistinguished Encoding Rules(DER)[X.509-88]の両方を使用します。

Housley                     Standards Track                     [Page 1]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[1ページ]。

1.1.  Terminology

1.1. 用語

   In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
   described in [STDWORDS].

本書では、キーワードが解釈しなければならない、[STDWORDS]で説明されるようにNOT、REQUIRED、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?

1.2.  Version Numbers

1.2. バージョン番号

   The major data structure (AuthEnvelopedData) includes a version
   number as the first item in the data structure.  The version number
   is intended to avoid ASN.1 decode errors.  Some implementations do
   not check the version number prior to attempting a decode, and then
   if a decode error occurs, the version number is checked as part of
   the error handling routine.  This is a reasonable approach; it places
   error processing outside of the fast path.  This approach is also
   forgiving when an incorrect version number is used by the sender.

主要なデータ構造(AuthEnvelopedData)はデータ構造における最初の項目としてバージョン番号を含んでいます。 バージョン番号は意図して、ASN.1を避けるのが誤りを解読するということです。 aを試みるのが解読する前いくつかの実装はバージョン番号をチェックしません、そして、次に、aが解読するなら、誤りは発生します、そして、バージョン番号はエラー処理ルーチンの一部としてチェックされます。 これは合理的なアプローチです。 それは高速経路の外にエラー処理を置きます。 また、不正確なバージョン番号が送付者によって使用されるとき、このアプローチは許されています。

   Whenever the structure is updated, a higher version number will be
   assigned.  However, to ensure maximum interoperability, the higher
   version number is only used when the new syntax feature is employed.
   That is, the lowest version number that supports the generated syntax
   is used.

構造をアップデートするときはいつも、より大きいバージョン番号は割り当てられるでしょう。 しかしながら、最大限のインターオペラビリティを確実にするために、新しい構文機能が採用しているときだけ、より大きいバージョン番号は使用されます。 すなわち、発生している構文をサポートする最も下位のバージョン番号は使用されています。

2.  Authenticated-Enveloped-Data Content Type

2. 認証されたおおわれたデータcontent type

   The authenticated-enveloped-data content type consists of an
   authenticated and encrypted content of any type and encrypted
   content-authenticated-encryption keys for one or more recipients.
   The combination of the authenticated and encrypted content and one
   encrypted content-authenticated-encryption key for a recipient is a
   "digital envelope" for that recipient.  Any type of content can be
   enveloped for an arbitrary number of recipients using any of the
   supported key management techniques for each recipient.  In addition,
   authenticated but not encrypted attributes may be provided by the
   originator.

認証されたおおわれたデータcontent typeは1人以上の受取人のためのどんなタイプと暗号化された内容が暗号化を認証しているキーの認証されて暗号化された内容からも成ります。 受取人のための認証されて暗号化された内容と1個の暗号化された内容が暗号化を認証しているキーの組み合わせはその受取人のための「デジタル封筒」です。 受取人の特殊活字の数字のために各受取人にサポートしているかぎ管理のテクニックのどれかを使用することでどんなタイプの内容もおおうことができます。 さらに、認証されましたが、暗号化されなかった属性は創始者によって提供されるかもしれません。

   The typical application of the authenticated-enveloped-data content
   type will represent one or more recipients' digital envelopes on an
   encapsulated content.

認証されたおおわれたデータcontent typeの主用途はカプセル化された内容に1人以上の受取人のデジタル封筒を表すでしょう。

   Authenticated-enveloped-data is constructed by the following steps:

認証されたおおわれたデータは以下のステップで構成されます:

   1.  A content-authenticated-encryption key for a particular content-
       authenticated-encryption algorithm is generated at random.

1. 特定の内容認証された暗号化アルゴリズムのための内容が暗号化を認証しているキーは無作為に生成されます。

Housley                     Standards Track                     [Page 2]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[2ページ]。

   2.  The content-authenticated-encryption key is encrypted for each
       recipient.  The details of this encryption depend on the key
       management algorithm used, but four general techniques are
       supported:

2. 内容が暗号化を認証しているキーは各受取人のために暗号化されます。 この暗号化の詳細は中古であるのにもかかわらずの、4つの一般的なテクニックがサポートされるかぎ管理アルゴリズムによります:

         Key Transport: the content-authenticated-encryption key is
            encrypted in the recipient's public key;

主要な輸送: 内容が暗号化を認証しているキーは受取人の公開鍵で暗号化されます。

         Key Agreement: the recipient's public key and the sender's
            private key are used to generate a pairwise symmetric key-
            encryption key, then the content-authenticated-encryption
            key is encrypted in the pairwise symmetric key-encryption
            key;

主要な協定: 受取人の公開鍵と送付者の秘密鍵は対状の左右対称の主要な暗号化キーを生成するのに使用されます、次に、内容が暗号化を認証しているキーは対状の左右対称の主要な暗号化キーで暗号化されます。

         Symmetric Key-Encryption Keys: the content-authenticated-
            encryption key is encrypted in a previously distributed
            symmetric key-encryption key; and

左右対称の主要な暗号化キー: 内容で認証された暗号化のキーは以前に分配された左右対称の主要な暗号化キーで暗号化されます。 そして

         Passwords: the content-authenticated-encryption key is
            encrypted in a key-encryption key that is derived from a
            password or other shared secret value.

パスワード: 内容が暗号化を認証しているキーはパスワードか他の共有秘密キー値から得られる主要な暗号化キーで暗号化されます。

   3.  For each recipient, the encrypted content-authenticated-
       encryption key and other recipient-specific information are
       collected into a RecipientInfo value, defined in Section 6.2 of
       [CMS].

3. 各受取人に関しては、暗号化された内容で認証された暗号化の主要で他の受取人特殊情報は[CMS]のセクション6.2で定義されたRecipientInfo値に集められます。

   4.  Any attributes that are to be authenticated but not encrypted are
       collected in the authenticated attributes.

4. 認証されますが、暗号化してはいけないどんな属性も認証された属性で集められます。

   5.  The attributes collected in step 4 are authenticated and the CMS
       content is authenticated and encrypted with the content-
       authenticated-encryption key.  If the authenticated encryption
       algorithm requires either the additional authenticated data (AAD)
       or the content to be padded to a multiple of some block size,
       then the padding is added as described in Section 6.3 of [CMS].

5. ステップ4に集められた属性が認証されて、CMS内容は、内容認証された暗号化キーで認証されて、暗号化されます。 認証された暗号化アルゴリズムが、追加認証されたデータ(AAD)か内容のどちらかが何らかのブロック・サイズの倍数に水増しされるのを必要とするなら、詰め物は[CMS]のセクション6.3で説明されるように加えられます。

   6.  Any attributes that are to be provided without authentication or
       encryption are collected in the unauthenticated attributes.

6. 認証も暗号化なしで提供されることになっているどんな属性も非認証された属性で集められます。

   7.  The RecipientInfo values for all the recipients, the
       authenticated attributes, the unauthenticated attributes, and the
       authenticated and encrypted content are collected together to
       form an AuthEnvelopedData value as defined in Section 2.1.

7. すべての受取人、認証された属性、非認証された属性、および認証されて暗号化された内容のためのRecipientInfo値は、セクション2.1で定義されるようにAuthEnvelopedData値を形成するために一緒に集められます。

Housley                     Standards Track                     [Page 3]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[3ページ]。

   A recipient opens the digital envelope by decrypting one of the
   encrypted content-authenticated-encryption keys, and then using the
   recovered key to decrypt and verify the integrity of the
   authenticated and encrypted content as well as to verify the
   integrity of the authenticated attributes.

受取人は、暗号化された内容が暗号化を認証しているキーの1つを解読して、次に、認証されて暗号化された内容の保全を解読して、確かめて、認証された属性の保全について確かめるのに回復しているキーを使用することによって、デジタル封筒を開けます。

   The recipient MUST verify the integrity of the received content
   before releasing any information, especially the plaintext of the
   content.  If the integrity verification fails, the receiver MUST
   destroy all of the plaintext of the content.

受取人はどんな情報も発表する前の受信された内容の保全、特に内容の平文について確かめなければなりません。 保全検証が失敗するなら、受信機は内容の平文のすべてを破壊しなければなりません。

   This section is divided into three parts.  The first part describes
   the AuthEnvelopedData content type, the second part describes the
   authentication and encryption process, and the third part describes
   the key encryption process.

このセクションは3つの部品に分割されます。 最初の部分はAuthEnvelopedData content typeについて説明します、そして、第二部は認証と暗号化プロセスについて説明します、そして、3番目の部分は主要な暗号化プロセスについて説明します。

2.1.  AuthEnvelopedData Type

2.1. AuthEnvelopedDataはタイプします。

   The following object identifier identifies the authenticated-
   enveloped-data content type:

以下のオブジェクト識別子は認証されたおおわれたデータcontent typeを特定します:

      id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
          member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
          smime(16) ct(1) 23 }

イドct authEnvelopedData、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)ct(1)23をメンバーと同じくらい具体化させます。

   The authenticated-enveloped-data content type MUST have ASN.1 type
   AuthEnvelopedData:

認証されたおおわれたデータcontent typeで、ASN.1はAuthEnvelopedDataをタイプしなければなりません:

      AuthEnvelopedData ::= SEQUENCE {
        version CMSVersion,
        originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
        recipientInfos RecipientInfos,
        authEncryptedContentInfo EncryptedContentInfo,
        authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
        mac MessageAuthenticationCode,
        unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

AuthEnvelopedData:、:= 系列バージョンCMSVersion、originatorInfo[0]IMPLICIT OriginatorInfo OPTIONAL、recipientInfos RecipientInfos、authEncryptedContentInfo EncryptedContentInfo authAttrs[1]IMPLICIT AuthAttributes OPTIONAL、mac MessageAuthenticationCode、unauthAttrs[2]IMPLICIT UnauthAttributes OPTIONAL

   The fields of type AuthEnvelopedData have the following meanings:

タイプAuthEnvelopedDataの分野には、以下の意味があります:

      version is the syntax version number.  It MUST be set to 0.

バージョンは構文バージョン番号です。 0にそれを設定しなければなりません。

      originatorInfo optionally provides information about the
         originator.  It is present only if required by the key
         management algorithm.  It may contain certificates and
         Certificate Revocation Lists (CRLs), and the OriginatorInfo
         type is defined in Section 6.1 of [CMS].

originatorInfoは任意に創始者の情報を提供します。 それは必要なら単にかぎ管理アルゴリズムで存在しています。 それは証明書とCertificate Revocation Lists(CRLs)を含むかもしれません、そして、OriginatorInfoタイプは[CMS]のセクション6.1で定義されます。

Housley                     Standards Track                     [Page 4]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[4ページ]。

      recipientInfos is a collection of per-recipient information.
         There MUST be at least one element in the collection.  The
         RecipientInfo type is defined in Section 6.2 of [CMS].

recipientInfosは1受取人あたりの情報の収集です。 収集には少なくとも1つの要素があるに違いありません。 RecipientInfoタイプは[CMS]のセクション6.2で定義されます。

      authEncryptedContentInfo is the authenticated and encrypted
         content.  The CMS enveloped-data content type uses the same
         type to carry the encrypted content.  The EncryptedContentInfo
         type is defined in Section 6.1 of [CMS].

authEncryptedContentInfoは認証されて暗号化された内容です。 CMSおおわれたデータcontent typeは、暗号化された内容を運ぶのに同じタイプを使用します。 EncryptedContentInfoタイプは[CMS]のセクション6.1で定義されます。

      authAttrs optionally contains the authenticated attributes.  The
         CMS authenticated-data content type uses the same type to carry
         authenticated attributes.  The authAttrs MUST be present if the
         content type carried in EncryptedContentInfo is not id-data.
         AuthAttributes MUST be DER encoded, even if the rest of the
         AuthEnvelopedData structure is BER encoded.  The AuthAttributes
         type is defined in Section 9.1 of [CMS]; however, in this case,
         the message-digest attribute SHOULD NOT be included.  Useful
         attribute types are defined in Section 11 of [CMS].

authAttrsは任意に認証された属性を含んでいます。 CMS認証されたデータcontent typeは、認証された属性を運ぶのに同じタイプを使用します。 authAttrsはEncryptedContentInfoで運ばれたcontent typeがイドデータでないなら存在していなければなりません。 AuthAttributesはAuthEnvelopedData構造の残りがコード化されたBERであってもコード化されたDERであるに違いありません。 AuthAttributesタイプは[CMS]のセクション9.1で定義されます。 この場合メッセージダイジェストがどのようにSHOULD NOTを結果と考えても、含められてください。 役に立つ属性タイプは[CMS]のセクション11で定義されます。

      mac is the integrity check value (ICV) or message authentication
         code (MAC) that is generated by the authenticated encryption
         algorithm.  The CMS authenticated-data content type uses the
         same type to carry a MAC.  In this case, the MAC covers the
         authenticated attributes and the content directly, and a digest
         algorithm is not used.  The MessageAuthenticationCode type is
         defined in Section 9.1 of [CMS].

macは認証された暗号化アルゴリズムで生成される保全チェック価値(ICV)かメッセージ確認コード(MAC)です。 CMS認証されたデータcontent typeは、MACを運ぶのに同じタイプを使用します。 この場合、MACは直接認証された属性と内容を含んでいます、そして、ダイジェストアルゴリズムは使用されていません。 MessageAuthenticationCodeタイプは[CMS]のセクション9.1で定義されます。

      unauthAttrs optionally contains the unauthenticated attributes.
         The CMS authenticated-data content type uses the same type to
         carry unauthenticated attributes.  The UnauthAttributes type is
         defined in Section 9.1 of [CMS].  Useful attribute types are
         defined in Section 11 of [CMS].

unauthAttrsは任意に非認証された属性を含んでいます。 CMS認証されたデータcontent typeは、非認証された属性を運ぶのに同じタイプを使用します。 UnauthAttributesタイプは[CMS]のセクション9.1で定義されます。 役に立つ属性タイプは[CMS]のセクション11で定義されます。

2.2.  Authentication and Encryption Process

2.2. 認証と暗号化プロセス

   The content-authenticated-encryption key for the desired content-
   authenticated-encryption algorithm is randomly generated.

必要な内容認証された暗号化アルゴリズムのための内容が暗号化を認証しているキーは手当たりしだいに生成されます。

   If the authenticated encryption algorithm requires the content to be
   padded to a multiple of some block size, then the padding MUST be
   added as described in Section 6.3 of [CMS].  This padding method is
   well defined if and only if the block size is less than 256 octets.

認証された暗号化アルゴリズムが、内容が何らかのブロック・サイズの倍数に水増しされるのを必要とするなら、詰め物として[CMS]のセクション6.3で説明されていた状態で加えなければなりません。 この詰め物メソッドがよく定義される、ブロック・サイズである場合にだけ、256未満の八重奏がそうです。

   If optional authenticated attributes are present, then they are DER
   encoded.  A separate encoding of the authAttrs field is performed to
   construct the authenticated associated data (AAD) input to the
   authenticated encryption algorithm.  For the purposes of constructing
   the AAD, the IMPLICIT [1] tag in the authAttrs field is not used for

任意の認証された属性が存在しているなら、それらはコード化されたDERです。 authAttrs分野の別々のコード化は、認証された関連データ(AAD)入力を認証された暗号化アルゴリズムに構成するために実行されます。 分野が使用されないauthAttrsでAAD、IMPLICIT[1]タグを組み立てる目的のために

Housley                     Standards Track                     [Page 5]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[5ページ]。

   the DER encoding: rather a universal SET OF tag is used.  That is,
   the DER encoding of the SET OF tag, rather than of the IMPLICIT [1]
   tag, is to be included in the construction for the AAD along with the
   length and content octets of the authAttrs value.  If the
   authenticated encryption algorithm requires the AAD to be padded to a
   multiple of some block size, then the padding MUST be added as
   described in Section 6.3 of [CMS].  This padding method is well
   defined if and only if the block size is less than 256 octets.

DERコード化: むしろ普遍的なSET OFタグは使用されています。 それは、DERがIMPLICIT[1]タグについてというよりむしろSET OFタグをコード化して、あって、authAttrs価値の長さと満足している八重奏に伴うAADのための工事に含まれることになっています。 認証された暗号化アルゴリズムが、AADが何らかのブロック・サイズの倍数に水増しされるのを必要とするなら、詰め物として[CMS]のセクション6.3で説明されていた状態で加えなければなりません。 この詰め物メソッドがよく定義される、ブロック・サイズである場合にだけ、256未満の八重奏がそうです。

   If optional authenticated attributes are absent, then zero bits of
   input are provided for the AAD input to the authenticated encryption
   algorithm.

任意の認証された属性が欠けるなら、認証された暗号化アルゴリズムへのAAD入力にゼロ・ビットの入力を提供します。

   The inputs to the authenticated encryption algorithm are the content
   (the data, which is padded if necessary), the DER-encoded
   authenticated attributes (the AAD, which is padded if necessary), and
   the content-authenticated-encryption key.  Under control of a
   content-authenticated-encryption key, the authenticated encryption
   operation maps an arbitrary string of octets (the data) to another
   string of octets (the ciphertext) and it computes an authentication
   tag over the AAD and the data.  The encrypted data is included in the
   AuthEnvelopedData authEncryptedContentInfo encryptedContent as an
   OCTET STRING, and the authentication tag is included in the
   AuthEnvelopedData mac.

認証された暗号化アルゴリズムへの入力は、内容(必要なら、水増しされるデータ)と、DERによってコード化された認証された属性(必要なら、水増しされるAAD)と、内容が暗号化を認証しているキーです。 内容が暗号化を認証しているキーで制御されています、認証された暗号化操作は八重奏(データ)の任意のストリングを八重奏(暗号文)の別のストリングに写像します、そして、それはAADとデータに関して認証タグを計算します。 暗号化されたデータはOCTET STRINGとしてAuthEnvelopedData authEncryptedContentInfo encryptedContentに含まれています、そして、認証タグはAuthEnvelopedData macに含まれています。

2.3.  Key Encryption Process

2.3. 主要な暗号化プロセス

   The input to the key encryption process -- the value supplied to the
   recipient's key-encryption algorithm -- is just the "value" of the
   content-authenticated-encryption key.

主要な暗号化プロセスへの入力(受取人の主要な暗号化アルゴリズムに供給された値)はまさしく内容が暗号化を認証しているキーの「値」です。

   Any of the aforementioned key management techniques can be used for
   each recipient of the same encrypted content.

同じ暗号化された内容の各受取人に前述のかぎ管理のテクニックのいずれも使用できます。

3.  Security Considerations

3. セキュリティ問題

   This specification defines an additional CMS content type.  The
   security considerations provided in [CMS] apply to this content type
   as well.

この仕様は追加CMS content typeを定義します。 [CMS]に提供されたセキュリティ問題はまた、このcontent typeに適用されます。

   Many authenticated encryption algorithms make use of a block cipher
   in counter mode to provide encryption.  When used properly, counter
   mode provides strong confidentiality.  Bellare, Desai, Jokipii, and
   Rogaway show in [BDJR] that the privacy guarantees provided by
   counter mode are at least as strong as those for Cipher Block
   Chaining (CBC) mode when using the same block cipher.

多くの認証された暗号化アルゴリズムが、暗号化を提供するのにカウンタモードでブロック暗号を利用します。 適切に使用されると、カウンタモードは強い秘密性を提供します。 Bellare、デセイ、Jokipii、およびRogawayは、[BDJR]にカウンタモードで提供されたプライバシー保証が同じブロックを使用するとき、Cipher Block Chaining(CBC)モードのためのそれらに解かれるのと少なくとも同じくらい強いのを示します。

Housley                     Standards Track                     [Page 6]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[6ページ]。

   Unfortunately, it is easy to misuse counter mode.  If counter block
   values are ever used for more that one encryption operation with the
   same key, then the same key stream will be used to encrypt both
   plaintexts, and the confidentiality guarantees are voided.

残念ながら、カウンタモードを誤用するのは簡単です。 カウンタブロック値が今までに以上に使用されると、同じ主要で、次に、同じ主要なストリームがあるその1つの暗号化操作が両方の平文を暗号化するのに使用されるでしょう、そして、秘密性保証は欠如します。

   Fortunately, the CMS authenticated-enveloped-data content type
   provides all of the tools needed to avoid misuse of counter mode.
   All of the existing key management techniques permit a fresh
   content-encryption key to be generated for each content.  In
   addition, existing authenticated encryption algorithms that make use
   of counter mode support the use of an unpredictable nonce value in
   the counter block.  This unpredictable nonce value (sometimes called
   a "salt") should be carried in an algorithm identifier parameter.

幸い、CMS認証されたおおわれたデータcontent typeはカウンタモードの誤用を避けるのに必要であるツールのすべてを提供します。 既存のかぎ管理のテクニックのすべてが各内容のために生成されるために主要な新鮮な満足している暗号化を可能にします。 さらに、存在はカウンタモードサポートの使用をカウンタブロックでの予測できない一回だけの値の使用にする暗号化アルゴリズムを認証しました。 この予測できない一回だけの値(時々「塩」と呼ばれる)はアルゴリズム識別子パラメタで運ばれるべきです。

   Implementations must randomly generate content-authenticated-
   encryption keys, padding, and unpredictable nonce values.  Also, the
   generation of public/private key pairs relies on a random numbers.
   The use of inadequate pseudo-random number generators (PRNGs) to
   generate cryptographic keys can result in little or no security.  An
   attacker may find it much easier to reproduce the PRNG environment
   that produced the keys, and then 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 4086
   [RANDOM] offers important guidance in this area.

実装は手当たりしだいに内容で認証された暗号化キーの、そして、詰め物の、そして、予測できない一回だけの値を生成しなければなりません。 また、公衆/秘密鍵組の世代は乱数を当てにします。 暗号化キーを生成する不十分な疑似乱数生成器(PRNGs)の使用はまずセキュリティをもたらすことができません。 攻撃者は、キーを生産したPRNG環境を再生させるのがはるかに簡単であることがわかるかもしれません、そして、次に、探して、獣よりむしろ結果として起こる小さい可能性は全体の主要なスペースを探すのに強制します。 上質の乱数の世代は難しいです。 RFC4086[RANDOM]はこの領域で重要な指導を提供します。

   If the message-digest attribute is included in the AuthAttributes,
   then the attribute value will contain the unencrypted one-way hash
   value of the plaintext of the content.  Disclosure of this hash value
   enables content tracking, and it can be used to determine if the
   plaintext matches one or more candidate contents.  For these reasons,
   the AuthAttributes SHOULD NOT contain the message-digest attribute.

メッセージダイジェスト属性がAuthAttributesに含まれていると、属性値は内容の平文の非暗号化された一方向ハッシュ値を含むでしょう。 このハッシュ値の公開は満足している追跡を可能にします、そして、平文が1人以上の候補のコンテンツに合っているかどうか決定するのにそれは使用できます。 これらの理由で、AuthAttributes SHOULDはメッセージダイジェスト属性を含んでいません。

   CMS is often used to provide encryption in messaging environments.
   In messaging environments, various forms of unsolicited messages
   (such as spam and phishing) represent a significant volume of
   unwanted traffic.  Present mitigation strategies for unwanted message
   traffic involve analysis of message plaintext.  When recipients
   accept unsolicited encrypted messages, they become even more
   vulnerable to unwanted traffic since many present mitigation
   strategies will be unable to access the plaintext.  Therefore,
   software that receives messages that have been encrypted using CMS
   needs to provide one or more mechanisms to handle the unwanted
   message traffic.  One approach that does not require disclosure of
   keying material to a server is to reject or discard encrypted
   messages unless they purport to come from a member of a white list.

CMSはメッセージング環境に暗号化を提供するのにおいてしばしば使用されています。 メッセージング環境で、様々なフォームに関するお節介なメッセージ(スパムやフィッシング詐欺などの)は求められていないトラフィックの重要な量を表します。 不要なメッセージトラフィックのための現在の緩和戦略はメッセージ平文の分析を伴います。 受取人が求められていない暗号化メッセージを受け入れるとき、多くの現在の緩和戦略が平文にアクセスできないので、それらは求められていないトラフィックにさらに被害を受け易くなります。 したがって、CMSを使用することで暗号化されたメッセージを受け取るソフトウェアは、不要なメッセージトラフィックを扱うために1つ以上のメカニズムを提供する必要があります。 ホワイトリストのメンバーから来ることを意味しないなら、サーバへの材料が拒絶することになっている合わせることの公開を必要としないか、または捨てられない1つのアプローチがメッセージを暗号化しました。

Housley                     Standards Track                     [Page 7]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[7ページ]。

4.  ASN.1 Module

4. ASN.1モジュール

   CMS-AuthEnvelopedData-2007
     { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
       pkcs-9(9) smime(16) modules(0) cms-authEnvelopedData(31) }

cm-AuthEnvelopedData-2007iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-authEnvelopedData(31)

   DEFINITIONS IMPLICIT TAGS ::=
   BEGIN

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

   -- EXPORTS All
   -- The types and values defined in this module are exported for use
   -- in the other ASN.1 modules.  Other applications may use them for
   -- their own purposes.

-- EXPORTS All--このモジュールで定義されたタイプと値は他のASN.1モジュールにおける使用のためにエクスポートされます。 アプリケーションがそれらを使用するかもしれないもう一方--それら自身の目的。

   IMPORTS

輸入

     -- Imports from RFC 3852 [CMS], Section 12.1
           AuthAttributes, CMSVersion, EncryptedContentInfo,
           MessageAuthenticationCode, OriginatorInfo, RecipientInfos,
           UnauthAttributes
              FROM CryptographicMessageSyntax2004
                   { iso(1) member-body(2) us(840) rsadsi(113549)
                     pkcs(1) pkcs-9(9) smime(16) modules(0)
                     cms-2004(24) } ;

-- RFC3852[CMS]、セクション12.1 AuthAttributes、CMSVersion、EncryptedContentInfo、MessageAuthenticationCode、OriginatorInfo、RecipientInfos、UnauthAttributes FROM CryptographicMessageSyntax2004からの輸入、iso(1)が(2) 私たちをメンバーと同じくらい具体化させる、(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)モジュール(0)cm-2004(24)、。

   id-ct-authEnvelopedData OBJECT IDENTIFIER ::= { iso(1)
       member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
       smime(16) ct(1) 23 }

イドct authEnvelopedData、オブジェクト識別子:、:= iso(1)は(2) 私たち(840)rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)ct(1)23をメンバーと同じくらい具体化させます。

   AuthEnvelopedData ::= SEQUENCE {
     version CMSVersion,
     originatorInfo [0] IMPLICIT OriginatorInfo OPTIONAL,
     recipientInfos RecipientInfos,
     authEncryptedContentInfo EncryptedContentInfo,
     authAttrs [1] IMPLICIT AuthAttributes OPTIONAL,
     mac MessageAuthenticationCode,
     unauthAttrs [2] IMPLICIT UnauthAttributes OPTIONAL }

AuthEnvelopedData:、:= 系列バージョンCMSVersion、originatorInfo[0]IMPLICIT OriginatorInfo OPTIONAL、recipientInfos RecipientInfos、authEncryptedContentInfo EncryptedContentInfo authAttrs[1]IMPLICIT AuthAttributes OPTIONAL、mac MessageAuthenticationCode、unauthAttrs[2]IMPLICIT UnauthAttributes OPTIONAL

   END -- of CMS-AuthEnvelopedData-2007

終わり--cm-AuthEnvelopedData-2007について

Housley                     Standards Track                     [Page 8]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[8ページ]。

5.  References

5. 参照

5.1.  Normative References

5.1. 引用規格

   [CMS]        Housley, R., "Cryptographic Message Syntax (CMS)", RFC
                3852, July 2004.

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

   [STDWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", BCP 14, RFC 2119, March 1997.

[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

5.2.  Informative References

5.2. 有益な参照

   [AESALGS]    Housley, R., "Using AES-CCM and AES-GCM Authenticated
                Encryption in the Cryptographic Message Syntax (CMS)",
                RFC 5084, November 2007.

[AESALGS]Housley、R.、「暗号のメッセージ構文(cm)でAES-立方センチメートルを使用して、AES-GCMは暗号化を認証した」RFC5084、2007年11月。

   [BDJR]       Bellare, M., Desai, A., Jokipii, E., and P. Rogaway, "A
                Concrete Security Treatment of Symmetric Encryption:
                Analysis of the DES Modes of Operation", Proceedings
                38th Annual Symposium on Foundations of Computer
                Science, 1997.

[BDJR] Bellare、M.、デセイ、A.、Jokipii、E.、およびP.Rogaway、「左右対称の暗号化の具体的なセキュリティ処理:」 「DES運転モードの分析」、コンピュータサイエンスの財団、1997に関する議事第38年次シンポジウム。

   [RANDOM]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                "Randomness Requirements for Security", BCP 106, RFC
                4086, June 2005.

イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。

Author's Address

作者のアドレス

   Russell Housley
   Vigil Security, LLC
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   EMail: housley@vigilsec.com

ラッセルHousley不寝番セキュリティ、LLC918春の小山Driveヴァージニア20170ハーンドン(米国)メール: housley@vigilsec.com

Housley                     Standards Track                     [Page 9]

RFC 5083              Authenticated-Enveloped-Data         November 2007

Housley規格は認証されたおおわれたデータ2007年11月にRFC5083を追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。

Housley                     Standards Track                    [Page 10]

Housley標準化過程[10ページ]