RFC3278 日本語訳

3278 Use of Elliptic Curve Cryptography (ECC) Algorithms inCryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P.Lambert. April 2002. (Format: TXT=33779 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                    S. Blake-Wilson
Request for Comments: 3278                                      D. Brown
Category: Informational                                    Certicom Corp
                                                              P. Lambert
                                                   Cosine Communications
                                                              April 2002

コメントを求めるワーキンググループS.ブレーク-ウィルソンの要求をネットワークでつないでください: 3278年のD.ブラウンカテゴリ: 情報のCerticom Corp P.ランバートコサインコミュニケーション2002年4月

          Use of Elliptic Curve Cryptography (ECC) Algorithms
                 in Cryptographic Message Syntax (CMS)

暗号のメッセージ構文における楕円曲線暗号(ECC)アルゴリズムの使用(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 (2002).  All Rights Reserved.

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

Abstract

要約

   This document describes how to use Elliptic Curve Cryptography (ECC)
   public-key algorithms in the Cryptographic Message Syntax (CMS).  The
   ECC algorithms support the creation of digital signatures and the
   exchange of keys to encrypt or authenticate content.  The definition
   of the algorithm processing is based on the ANSI X9.62 standard,
   developed by the ANSI X9F1 working group, the IEEE 1363 standard, and
   the SEC 1 standard.

このドキュメントはCryptographic Message Syntax(CMS)のElliptic Curve Cryptography(ECC)公開鍵アルゴリズムを使用する方法を説明します。 ECCアルゴリズムは、内容を暗号化するか、または認証するためにデジタル署名の作成とキーの交換をサポートします。 アルゴリズム処理の定義はANSI X9F1ワーキンググループ、1363年のIEEE規格、およびSEC1規格によって開発されたANSI X9.62規格に基づいています。

   The readers attention is called to the Intellectual Property Rights
   section at the end of this document.

読者注意はこのドキュメントの端のIntellectual Property Rights部に呼ばれます。

Blake-Wilson, et al.         Informational                      [Page 1]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[1ページ]のRFC3278使用

Table of Contents

目次

   1  Introduction ................................................... 2
      1.1  Requirements terminology .................................. 3
   2  SignedData using ECC ..........................................  3
      2.1  SignedData using ECDSA ...................................  3
           2.1.1  Fields of the SignedData ..........................  3
           2.1.2  Actions of the sending agent ......................  4
           2.1.3  Actions of the receiving agent ....................  4
   3  EnvelopedData using ECC .......................................  4
      3.1  EnvelopedData using ECDH .................................  5
           3.1.1  Fields of KeyAgreeRecipientInfo ...................  5
           3.1.2  Actions of the sending agent ......................  5
           3.1.3  Actions of the receiving agent ....................  6
      3.2  EnvelopedData using 1-Pass ECMQV .........................  6
           3.2.1  Fields of KeyAgreeRecipientInfo ...................  6
           3.2.2  Actions of the sending agent ......................  7
           3.2.3  Actions of the receiving agent ....................  7
   4  AuthenticatedData using ECC ............ ......................  8
      4.1  AuthenticatedData using 1-pass ECMQV .....................  8
           4.1.1  Fields of KeyAgreeRecipientInfo ...................  8
           4.1.2  Actions of the sending agent ......................  8
           4.1.3  Actions of the receiving agent ....................  8
   5  Recommended Algorithms and Elliptic Curves ....................  9
   6  Certificates using ECC ........................................  9
   7  SMIMECapabilities Attribute and ECC ...........................  9
   8  ASN.1 Syntax .................................................. 10
      8.1  Algorithm identifiers .................................... 10
      8.2  Other syntax ............................................. 11
   9  Summary ....................................................... 12
   References ....................................................... 13
   Security Considerations .......................................... 14
   Intellectual Property Rights ..................................... 14
   Acknowledgments .................................................. 15
   Authors' Addresses ............................................... 15
   Full Copyright Statement ......................................... 16

1つの序論… 2 1.1 要件用語… ECCを使用する3 2SignedData… 3 ECDSAを使用する2.1SignedData… 3 2.1 .1 SignedDataのフィールズ… 3 2.1 送付エージェントの.2の動作… 4 2.1 受信エージェントの.3の動作… ECCを使用する4 3EnvelopedData… 4 ECDHを使用する3.1EnvelopedData… 5 3.1 .1 KeyAgreeRecipientInfoのフィールズ… 5 3.1 送付エージェントの.2の動作… 5 3.1 受信エージェントの.3の動作… 6 1パスのECMQVを使用する3.2EnvelopedData… 6 3.2 .1 KeyAgreeRecipientInfoのフィールズ… 6 3.2 送付エージェントの.2の動作… 7 3.2 受信エージェントの.3の動作… ECCを使用する7 4AuthenticatedData… ...................... 8 1パスのECMQVを使用する4.1AuthenticatedData… 8 4.1 .1 KeyAgreeRecipientInfoのフィールズ… 8 4.1 送付エージェントの.2の動作… 8 4.1 受信エージェントの.3の動作… 8 5のお勧めのアルゴリズムと楕円曲線… ECCを使用する9 6通の証明書… 9 7のSMIMECapabilities属性とECC… 9 8ASN.1構文… 10 8.1 アルゴリズム識別子… 10 他の8.2構文… 11 9概要… 12の参照箇所… 13 セキュリティ問題… 14知的所有権はまっすぐになります… 14の承認… 15人の作者のアドレス… 15 完全な著作権宣言文… 16

1  Introduction

1つの序論

   The Cryptographic Message Syntax (CMS) is cryptographic algorithm
   independent.  This specification defines a profile for the use of
   Elliptic Curve Cryptography (ECC) public key algorithms in the CMS.
   The ECC algorithms are incorporated into the following CMS content
   types:

Cryptographic Message Syntax(CMS)は暗号アルゴリズム独立者です。 この仕様はCMSにおけるElliptic Curve Cryptography(ECC)公開鍵アルゴリズムの使用のためのプロフィールを定義します。ECCアルゴリズムは以下のCMS content typeに組み入れられます:

      -  'SignedData' to support ECC-based digital signature methods
         (ECDSA) to sign content

- ECCベースのデジタル署名が内容に署名するメソッド(ECDSA)であるとサポートする'SignedData'

Blake-Wilson, et al.         Informational                      [Page 2]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[2ページ]のRFC3278使用

      -  'EnvelopedData' to support ECC-based public-key agreement
         methods (ECDH and ECMQV) to generate pairwise key-encryption
         keys to encrypt content-encryption keys used for content
         encryption

- ECCベースの公開鍵協定が内容に使用される満足している暗号化キーを暗号化するために対状主要な暗号化キーを生成するメソッド(ECDHとECMQV)であるとサポートする'EnvelopedData'暗号化

      -  'AuthenticatedData' to support ECC-based public-key agreement
         methods (ECMQV) to generate pairwise key-encryption keys to
         encrypt MAC keys used for content authentication and integrity

- ECCベースの公開鍵協定が満足している認証と保全に使用されるMACキーを暗号化するために対状主要な暗号化キーを生成するメソッド(ECMQV)であるとサポートする'AuthenticatedData'

   Certification of EC public keys is also described to provide public-
   key distribution in support of the specified techniques.

また、EC公開鍵の証明は、指定されたテクニックを支持して公共の主要な分配を提供するために説明されます。

1.1  Requirements terminology

1.1 要件用語

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

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

2  SignedData using ECC

2 ECCを使用するSignedData

   This section describes how to use ECC algorithms with the CMS
   SignedData format to sign data.

このセクションは、データに署名するためにCMS SignedData形式でECCアルゴリズムを使用する方法を説明します。

2.1  SignedData using ECDSA

2.1 ECDSAを使用するSignedData

   This section describes how to use the Elliptic Curve Digital
   Signature Algorithm (ECDSA) with SignedData.  ECDSA is specified in
   [X9.62].  The method is the elliptic curve analog of the Digital
   Signature Algorithm (DSA) [FIPS 186-2].

このセクションはSignedDataと共にElliptic Curve Digital Signature Algorithm(ECDSA)を使用する方法を説明します。 ECDSAは[X9.62]で指定されます。 メソッドはDigital Signature Algorithm(DSA)[FIPS186-2]の楕円曲線アナログです。

   In an implementation that uses ECDSA with CMS SignedData, the
   following techniques and formats MUST be used.

CMS SignedDataとECDSAを使用する実装では、以下のテクニックと形式を使用しなければなりません。

2.1.1  Fields of the SignedData

2.1.1 SignedDataの分野

   When using ECDSA with SignedData, the fields of SignerInfo are as in
   [CMS], but with the following restrictions:

SignedDataとECDSAを使用するとき、SignerInfoの分野が[CMS]にもかかわらず、以下の制限と共にあります:

      digestAlgorithm MUST contain the algorithm identifier sha-1 (see
      Section 8.1) which identifies the SHA-1 hash algorithm.

digestAlgorithmはSHA-1ハッシュアルゴリズムを特定するアルゴリズム識別子sha-1(セクション8.1を見る)を含まなければなりません。

      signatureAlgorithm contains the algorithm identifier ecdsa-with-
      SHA1 (see Section 8.1) which identifies the ECDSA signature
      algorithm.

signatureAlgorithmがアルゴリズム識別子ecdsaを含んでいる、-SHA1(セクション8.1を見る)と共に、どれがECDSA署名アルゴリズムを特定しますか?

      signature MUST contain the DER encoding (as an octet string) of a
      value of the ASN.1 type ECDSA-Sig-Value (see Section 8.2).

署名はASN.1タイプECDSA-Sig-価値の値のDERコード化(八重奏ストリングとしての)を含まなければなりません(セクション8.2を見てください)。

Blake-Wilson, et al.         Informational                      [Page 3]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[3ページ]のRFC3278使用

   When using ECDSA, the SignedData certificates field MAY include the
   certificate(s) for the EC public key(s) used in the generation of the
   ECDSA signatures in SignedData.  ECC certificates are discussed in
   Section 6.

ECDSAを使用するとき、SignedData証明書分野はSignedDataのECDSA署名の世代に使用されるEC公開鍵のための証明書を含むかもしれません。 セクション6でECC証明書について議論します。

2.1.2  Actions of the sending agent

2.1.2 送付エージェントの動作

   When using ECDSA with SignedData, the sending agent uses the message
   digest calculation process and signature generation process for
   SignedData that are specified in [CMS].  To sign data, the sending
   agent uses the signature method specified in [X9.62, Section 5.3]
   with the following exceptions:

SignedDataとECDSAを使用するとき、送付エージェントは[CMS]で指定されるSignedDataにメッセージダイジェスト計算過程と署名発生経過を使用します。 データに署名するために、送付エージェントは[X9.62、セクション5.3]で以下の例外で指定された署名メソッドを使用します:

      -  In [X9.62, Section 5.3.1], the integer "e" is instead
         determined by converting the message digest generated according
         to [CMS, Section 5.4] to an integer using the data conversion
         method in [X9.62, Section 4.3.2].

- [X9.62、セクション5.3.1]では、整数「e」は、代わりに[X9.62、セクション4.3.2]にデータ変換メソッドを使用しながら、[CMS、セクション5.4]に応じて発生しているメッセージダイジェストを整数に変換することによって、測定されます。

   The sending agent encodes the resulting signature using the ECDSA-
   Sig-Value syntax (see Section 8.2) and places it in the SignerInfo
   signature field.

送付エージェントは、ECDSA- Sig-値の構文(セクション8.2を見る)を使用することで結果として起こる署名をコード化して、SignerInfo署名分野にそれを置きます。

2.1.3  Actions of the receiving agent

2.1.3 受信エージェントの動作

   When using ECDSA with SignedData, the receiving agent uses the
   message digest calculation process and signature verification process
   for SignedData that are specified in [CMS].  To verify SignedData,
   the receiving agent uses the signature verification method specified
   in [X9.62, Section 5.4] with the following exceptions:

SignedDataとECDSAを使用するとき、受信エージェントは[CMS]で指定されるSignedDataにメッセージダイジェスト計算過程と署名照合プロセスを使用します。 SignedDataについて確かめるために、受信エージェントは[X9.62、セクション5.4]で以下の例外で指定された署名照合メソッドを使用します:

      -  In [X9.62, Section 5.4.1] the integer "e'" is instead
         determined by converting the message digest generated according
         to [CMS, Section 5.4] to an integer using the data conversion
         method in [X9.62, Section 4.3.2].

- '[X9.62、セクション5.4.1]整数「e'」は、代わりに[X9.62、セクション4.3.2]にデータ変換メソッドを使用しながら、[CMS、セクション5.4]に応じて発生しているメッセージダイジェストを整数に変換することによって、決定します。

   In order to verify the signature, the receiving agent retrieves the
   integers r and s from the SignerInfo signature field of the received
   message.

署名について確かめるために、受信エージェントは受信されたメッセージのSignerInfo署名分野から整数rとsを検索します。

3  EnvelopedData using ECC Algorithms

3 ECCアルゴリズムを使用するEnvelopedData

   This section describes how to use ECC algorithms with the CMS
   EnvelopedData format.

このセクションはCMS EnvelopedData形式でECCアルゴリズムを使用する方法を説明します。

Blake-Wilson, et al.         Informational                      [Page 4]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[4ページ]のRFC3278使用

3.1  EnvelopedData using (ephemeral-static) ECDH

3.1 (はかなく静的)のECDHを使用するEnvelopedData

   This section describes how to use the ephemeral-static Elliptic Curve
   Diffie-Hellman (ECDH) key agreement algorithm with EnvelopedData.
   Ephemeral-static ECDH is specified in [SEC1] and [IEEE1363].
   Ephemeral-static ECDH is the the elliptic curve analog of the
   ephemeral-static Diffie-Hellman key agreement algorithm specified
   jointly in the documents [CMS, Section 12.3.1.1] and [CMS-DH].

このセクションはEnvelopedDataと共にはかなく静的なElliptic Curveディフィー-ヘルマン(ECDH)の主要な協定アルゴリズムを使用する方法を説明します。 はかなく静的なECDHは[SEC1]と[IEEE1363]で指定されます。 はかなく静的なECDHはドキュメントで共同で指定されたはかなく静的なディフィー-ヘルマン主要な協定アルゴリズムの楕円曲線アナログです。[CMS、セクション12.3.1.1と][CMS-DH]。

   In an implementation that uses ECDH with CMS EnvelopedData with key
   agreement, the following techniques and formats MUST be used.

主要な協定と共にCMS EnvelopedDataとECDHを使用する実装では、以下のテクニックと形式を使用しなければなりません。

3.1.1  Fields of KeyAgreeRecipientInfo

3.1.1 KeyAgreeRecipientInfoの分野

   When using ephemeral-static ECDH with EnvelopedData, the fields of
   KeyAgreeRecipientInfo are as in [CMS], but with the following
   restrictions:

EnvelopedDataとはかなく静的なECDHを使用するとき、KeyAgreeRecipientInfoの分野が[CMS]にもかかわらず、以下の制限と共にあります:

      originator MUST be the alternative originatorKey.  The
      originatorKey algorithm field MUST contain the id-ecPublicKey
      object identifier (see Section 8.1) with NULL parameters.  The
      originatorKey publicKey field MUST contain the DER-encoding of a
      value of the ASN.1 type ECPoint (see Section 8.2), which
      represents the sending agent's ephemeral EC public key.

創始者は代替のoriginatorKeyであるに違いありません。 originatorKeyアルゴリズム分野はNULLパラメタでイド-ecPublicKeyオブジェクト識別子を含まなければなりません(セクション8.1を見ます)。 originatorKey publicKey分野は送付エージェントのはかないEC公開鍵を表すASN.1タイプECPoint(セクション8.2を見る)の価値のDER-コード化を含まなければなりません。

      keyEncryptionAlgorithm MUST contain the dhSinglePass-stdDH-
      sha1kdf-scheme object identifier (see Section 8.1) if standard
      ECDH primitive is used, or the dhSinglePass-cofactorDH-sha1kdf-
      scheme object identifier (see Section 8.1) if the cofactor ECDH
      primitive is used.  The parameters field contains
      KeyWrapAlgorithm.  The KeyWrapAlgorithm is the algorithm
      identifier that indicates the symmetric encryption algorithm used
      to encrypt the content-encryption key (CEK) with the key-
      encryption key (KEK).

標準のECDH基関数が使用されているならkeyEncryptionAlgorithmがdhSinglePass-stdDH- sha1kdf-体系オブジェクト識別子(セクション8.1を見る)を含まなければならない、さもなければ、dhSinglePass-cofactorDH-sha1kdf体系オブジェクト識別子(セクション8.1を見る)は補助因子ECDH基関数であるなら使用されています。 パラメタ分野はKeyWrapAlgorithmを含んでいます。 KeyWrapAlgorithmは左右対称の暗号化アルゴリズムが以前は、よく満足している暗号化の主要な暗号化によって主要な(CEK)キー(KEK)を暗号化していたのを示すアルゴリズム識別子です。

3.1.2  Actions of the sending agent

3.1.2 送付エージェントの動作

   When using ephemeral-static ECDH with EnvelopedData, the sending
   agent first obtains the recipient's EC public key and domain
   parameters (e.g. from the recipient's certificate).  The sending
   agent then determines an integer "keydatalen", which is the
   KeyWrapAlgorithm symmetric key-size in bits, and also a bit string
   "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see
   Section 8.2).  The sending agent then performs the key deployment and
   the key agreement operation of the Elliptic Curve Diffie-Hellman
   Scheme specified in [SEC1, Section 6.1].  As a result the sending
   agent obtains:

EnvelopedDataとはかなく静的なECDHを使用するとき、送付エージェントは最初に、受取人のEC公開鍵とドメインパラメタ(例えば、受取人の証明書からの)を得ます。 そして、送付エージェントは整数"keydatalen"を決定します(セクション8.2を見てください)。(それは、ビットと、少しもKeyWrapAlgorithmの左右対称の主要なサイズストリング"SharedInfo"であり、ECC-CMS-SharedInfoのDERコード化です)。 そして送付エージェントは[SEC1、セクション6.1]で指定されたElliptic Curveディフィー-ヘルマンSchemeの主要な展開と主要な協定操作を実行します。 その結果、送付エージェントは以下を得ます。

Blake-Wilson, et al.         Informational                      [Page 5]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[5ページ]のRFC3278使用

      -  an ephemeral public key, which is represented as a value of the
         type ECPoint (see Section 8.2), encapsulated in a bit string
         and placed in the KeyAgreeRecipientInfo originator field, and

- そしてはかない公開鍵。(それは、しばらくストリングでカプセル化されて、KeyAgreeRecipientInfo創始者分野に置かれたタイプECPoint(セクション8.2を見る)の値として表されます)。

      -  a shared secret bit string "K", which is used as the pairwise
         key-encryption key for that recipient, as specified in [CMS].

- [cm]のその受取人にとって、指定されるとして主要な対状主要な暗号化として使用される共有された秘密のビット列「K。」

3.1.3  Actions of the receiving agent

3.1.3 受信エージェントの動作

   When using ephemeral-static ECDH with EnvelopedData, the receiving
   agent determines the bit string "SharedInfo", which is the DER
   encoding of ECC-CMS-SharedInfo (see Section 8.2), and the integer
   "keydatalen" from the key-size, in bits, of the KeyWrapAlgorithm.
   The receiving agent retrieves the ephemeral EC public key from the
   bit string KeyAgreeRecipientInfo originator, with a value of the type
   ECPoint (see Section 8.2) encapsulated as a bit string.  The
   receiving agent performs the key agreement operation of the Elliptic
   Curve Diffie-Hellman Scheme specified in [SEC1, Section 6.1].  As a
   result, the receiving agent obtains a shared secret bit string "K",
   which is used as the pairwise key-encryption key to unwrap the CEK.

EnvelopedDataとはかなく静的なECDHを使用するとき、受信エージェントは主要なサイズからECC-CMS-SharedInfoのDERコード化であるビット列"SharedInfo"(セクション8.2を見る)、および整数"keydatalen"を決定します、KeyWrapAlgorithmのビットで。 受信エージェントはビット列KeyAgreeRecipientInfo創始者からはかないEC公開鍵を検索します、タイプECPoint(セクション8.2を見る)の値がしばらくストリングとしてカプセル化されている状態で。 受信エージェントは[SEC1、セクション6.1]で指定されたElliptic Curveディフィー-ヘルマンSchemeの主要な協定操作を実行します。 その結果、受信エージェントは共有された秘密のビット列「K」を得ます。(それは、CEKを開けるために主要な対状主要な暗号化として使用されます)。

3.2  EnvelopedData using 1-Pass ECMQV

3.2 1パスのECMQVを使用するEnvelopedData

   This section describes how to use the 1-Pass elliptic curve MQV
   (ECMQV) key agreement algorithm with EnvelopedData.  ECMQV is
   specified in [SEC1] and [IEEE1363].  Like the KEA algorithm [CMS-
   KEA], 1-Pass ECMQV uses three key pairs: an ephemeral key pair, a
   static key pair of the sending agent, and a static key pair of the
   receiving agent.  An advantage of using 1-Pass ECMQV is that it can
   be used with both EnvelopedData and AuthenticatedData.

このセクションはEnvelopedDataと共に1パスの楕円曲線MQV(ECMQV)主要な協定アルゴリズムを使用する方法を説明します。 ECMQVは[SEC1]と[IEEE1363]で指定されます。 KEAアルゴリズム[CMS- KEA]のように、1パスのECMQVは主要な3組を使用します: はかない主要な組、送付エージェントの静的な主要な組、および受信エージェントの静的な主要な組。 1パスのECMQVを使用する利点はEnvelopedDataとAuthenticatedDataの両方と共にそれを使用できるということです。

   In an implementation that uses 1-Pass ECMQV with CMS EnvelopedData
   with key agreement, the following techniques and formats MUST be
   used.

主要な協定と共にCMS EnvelopedDataと1パスのECMQVを使用する実装では、以下のテクニックと形式を使用しなければなりません。

3.2.1  Fields of KeyAgreeRecipientInfo

3.2.1 KeyAgreeRecipientInfoの分野

   When using 1-Pass ECMQV with EnvelopedData, the fields of
   KeyAgreeRecipientInfo are:

EnvelopedDataと1パスのECMQVを使用するとき、KeyAgreeRecipientInfoの分野は以下の通りです。

      originator identifies the static EC public key of the sender.  It
      SHOULD be one of the alternatives, issuerAndSerialNumber or
      subjectKeyIdentifier, and point to one of the sending agent's
      certificates.

創始者は送付者の静的なEC公開鍵を特定します。 それ、SHOULDは代替手段、issuerAndSerialNumberまたはsubjectKeyIdentifierの1つであり、送付エージェントの証明書の1つを示します。

      ukm MUST be present.  The ukm field MUST contain an octet string
      which is the DER encoding of the type MQVuserKeyingMaterial (see
      Section 8.2).  The MQVuserKeyingMaterial ephemeralPublicKey

ukmは存在していなければなりません。 ukm分野はMQVuserKeyingMaterialをタイプにコード化するDERである八重奏ストリングを含まなければなりません(セクション8.2を見てください)。 MQVuserKeyingMaterial ephemeralPublicKey

Blake-Wilson, et al.         Informational                      [Page 6]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[6ページ]のRFC3278使用

      algorithm field MUST contain the id-ecPublicKey object identifier
      (see Section 8.1) with NULL parameters field.  The
      MQVuserKeyingMaterial ephemeralPublicKey publicKey field MUST
      contain the DER-encoding of the ASN.1 type ECPoint (see Section
      8.2) representing sending agent's ephemeral EC public key.  The
      MQVuserKeyingMaterial addedukm field, if present, SHOULD contain
      an octet string of additional user keying material of the sending
      agent.

アルゴリズム分野はNULLパラメタ分野でイド-ecPublicKeyオブジェクト識別子を含まなければなりません(セクション8.1を見ます)。 送付エージェントのはかないECの公開鍵を表して、MQVuserKeyingMaterial ephemeralPublicKey publicKey分野はASN.1タイプECPoint(セクション8.2を見る)のDER-コード化を含まなければなりません。 MQVuserKeyingMaterial addedukm分野であり、存在しているなら、SHOULDは送付エージェントの材料を合わせる追加ユーザの八重奏ストリングを含んでいます。

      keyEncryptionAlgorithm MUST be the mqvSinglePass-sha1kdf-scheme
      algorithm identifier (see Section 8.1), with the parameters field
      KeyWrapAlgorithm. The KeyWrapAlgorithm indicates the symmetric
      encryption algorithm used to encrypt the CEK with the KEK
      generated using the 1-Pass ECMQV algorithm.

keyEncryptionAlgorithmはパラメタ分野KeyWrapAlgorithmがあるmqvSinglePass-sha1kdf-体系アルゴリズム識別子であるに違いありません(セクション8.1を見ます)。 KeyWrapAlgorithmは、KEKが生成されている状態で左右対称の暗号化アルゴリズムが以前は1パスのECMQVアルゴリズムを使用することでCEKをよく暗号化していたのを示します。

3.2.2  Actions of the sending agent

3.2.2 送付エージェントの動作

   When using 1-Pass ECMQV with EnvelopedData, the sending agent first
   obtains the recipient's EC public key and domain parameters, (e.g.
   from the recipient's certificate) and checks that the domain
   parameters are the same.  The sending agent then determines an
   integer "keydatalen", which is the KeyWrapAlgorithm symmetric key-
   size in bits, and also a bit string "SharedInfo", which is the DER
   encoding of ECC-CMS-SharedInfo (see Section 8.2).  The sending agent
   then performs the key deployment and key agreement operations of the
   Elliptic Curve MQV Scheme specified in [SEC1, Section 6.2].  As a
   result, the sending agent obtains:

そして、EnvelopedDataと1パスのECMQVを使用するとき、送付エージェントが最初に受取人のEC公開鍵とドメインパラメタを得る、(例えば、受取人の証明書からの)、ドメインパラメタが同じであることをチェックします。 そして、送付エージェントは整数"keydatalen"を決定します(セクション8.2を見てください)。(それは、ビットと、少しもKeyWrapAlgorithmの左右対称の主要なサイズストリング"SharedInfo"であり、ECC-CMS-SharedInfoのDERコード化です)。 そして送付エージェントは[SEC1、セクション6.2]で指定されたElliptic Curve MQV Schemeの主要な展開と主要な協定操作を実行します。 その結果、送付エージェントは以下を得ます。

      -  an ephemeral public key, which is represented as a value of
         type ECPoint (see Section 8.2), encapsulated in a bit string,
         placed in an MQVuserKeyingMaterial ephemeralPublicKey publicKey
         field (see Section 8.2), and

- そしてはかない公開鍵(タイプECPoint(セクション8.2を見る)の値として表される)がMQVuserKeyingMaterial ephemeralPublicKey publicKey分野(セクション8.2を見る)に置かれたしばらくストリングで要約された。

      -  a shared secret bit string "K", which is used as the pairwise
         key-encryption key for that recipient, as specified in [CMS].

- [cm]のその受取人にとって、指定されるとして主要な対状主要な暗号化として使用される共有された秘密のビット列「K。」

   The ephemeral public key can be re-used with an AuthenticatedData for
   greater efficiency.

より大きい効率にAuthenticatedDataと共にはかない公開鍵を再使用できます。

3.2.3  Actions of the receiving agent

3.2.3 受信エージェントの動作

   When using 1-Pass ECMQV with EnvelopedData, the receiving agent
   determines the bit string "SharedInfo", which is the DER encoding of
   ECC-CMS-SharedInfo (see Section 8.2), and the integer "keydatalen"
   from the key-size, in bits, of the KeyWrapAlgorithm.  The receiving
   agent then retrieves the static and ephemeral EC public keys of the
   originator, from the originator and ukm fields as described in
   Section 3.2.1, and its static EC public key identified in the rid

EnvelopedDataと1パスのECMQVを使用するとき、受信エージェントは主要なサイズからECC-CMS-SharedInfoのDERコード化であるビット列"SharedInfo"(セクション8.2を見る)、および整数"keydatalen"を決定します、KeyWrapAlgorithmのビットで。 次に、受信エージェントは創始者の静的ではかないEC公開鍵を検索します、創始者、セクション3.2.1で説明されるukm分野、および排除で特定されたその静的なEC公開鍵から

Blake-Wilson, et al.         Informational                      [Page 7]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[7ページ]のRFC3278使用

   field and checks that the domain parameters are the same.  The
   receiving agent then performs the key agreement operation of the
   Elliptic Curve MQV Scheme [SEC1, Section 6.2].  As a result, the
   receiving agent obtains a shared secret bit string "K" which is used
   as the pairwise key-encryption key to unwrap the CEK.

ドメインパラメタが同じであることをさばいて、チェックします。 そして、受信エージェントはElliptic Curve MQV Scheme[SEC1、セクション6.2]の主要な協定操作を実行します。 その結果、受信エージェントはCEKを開けるために主要な対状主要な暗号化として使用される共有された秘密のビット列「K」を得ます。

4  AuthenticatedData using ECC

4 ECCを使用するAuthenticatedData

   This section describes how to use ECC algorithms with the CMS
   AuthenticatedData format.  AuthenticatedData lacks non-repudiation,
   and so in some instances is preferable to SignedData.  (For example,
   the sending agent might not want the message to be authenticated when
   forwarded.)

このセクションはCMS AuthenticatedData形式でECCアルゴリズムを使用する方法を説明します。 AuthenticatedDataは、非拒否を欠いているので、SignedDataよりある場合に望ましいです。 (例えば、進める場合、送付エージェントは認証されるべきメッセージが欲しくないかもしれません。)

4.1  AuthenticatedData using 1-pass ECMQV

4.1 1パスのECMQVを使用するAuthenticatedData

   This section describes how to use the 1-Pass elliptic curve MQV
   (ECMQV) key agreement algorithm with AuthenticatedData.  ECMQV is
   specified in [SEC1].  An advantage of using 1-Pass ECMQV is that it
   can be used with both EnvelopedData and AuthenticatedData.

このセクションはAuthenticatedDataと共に1パスの楕円曲線MQV(ECMQV)主要な協定アルゴリズムを使用する方法を説明します。 ECMQVは[SEC1]で指定されます。 1パスのECMQVを使用する利点はEnvelopedDataとAuthenticatedDataの両方と共にそれを使用できるということです。

4.1.1  Fields of the KeyAgreeRecipientInfo

4.1.1 KeyAgreeRecipientInfoの分野

   The AuthenticatedData KeyAgreeRecipientInfo fields are used in the
   same manner as the fields for the corresponding EnvelopedData
   KeyAgreeRecipientInfo fields of Section 3.2.1 of this document.

AuthenticatedData KeyAgreeRecipientInfo分野はこの.1通のセクション3.2ドキュメントの対応するEnvelopedData KeyAgreeRecipientInfo分野に分野と同じ方法で使用されます。

4.1.2  Actions of the sending agent

4.1.2 送付エージェントの動作

   The sending agent uses the same actions as for EnvelopedData with 1-
   Pass ECMQV, as specified in Section 3.2.2 of this document.

送付エージェントは1パスECMQVと共にEnvelopedDataのように同じ動作を使用します、この.2通のセクション3.2ドキュメントで指定されるように。

   The ephemeral public key can be re-used with an EnvelopedData for
   greater efficiency.

より大きい効率にEnvelopedDataと共にはかない公開鍵を再使用できます。

   Note: if there are multiple recipients, an attack is possible where
   one recipient modifies the content without other recipients noticing
   [BON].  A sending agent who is concerned with such an attack SHOULD
   use a separate AuthenticatedData for each recipient.

以下に注意してください。 複数の受取人がいれば、1人の受取人が他の受取人なしで内容を変更するところで攻撃は、[BON]に気付きながら、可能です。 SHOULDが各受取人に別々のAuthenticatedDataを使用することをそのような攻撃に心配させる送付エージェント。

4.1.3  Actions of the receiving agent

4.1.3 受信エージェントの動作

   The receiving agent uses the same actions as for EnvelopedData with
   1-Pass ECMQV, as specified in Section 3.2.3 of this document.

受信エージェントは1パスのECMQVと共にEnvelopedDataのように同じ動作を使用します、この.3通のセクション3.2ドキュメントで指定されるように。

   Note: see Note in Section 4.1.2.

以下に注意してください。 セクション4.1.2でNoteを見てください。

Blake-Wilson, et al.         Informational                      [Page 8]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[8ページ]のRFC3278使用

5  Recommended Algorithms and Elliptic Curves

5 お勧めのアルゴリズムと楕円曲線

   Implementations of this specification MUST implement either
   SignedData with ECDSA or EnvelopedData with ephemeral-static ECDH.
   Implementations of this specification SHOULD implement both
   SignedData with ECDSA and EnvelopedData with ephemeral-static ECDH.
   Implementations MAY implement the other techniques specified, such as
   AuthenticatedData and 1-Pass ECMQV.

この仕様の実装ははかなく静的なECDHと共にECDSAとSignedDataかEnvelopedDataのどちらかを実装しなければなりません。 この仕様SHOULDの実装ははかなく静的なECDHと共にECDSAとSignedDataとEnvelopedDataの両方を実装します。 実装はAuthenticatedDataや1パスのECMQVのように指定された他のテクニックを実装するかもしれません。

   Furthermore, in order to encourage interoperability, implementations
   SHOULD use the elliptic curve domain parameters specified by ANSI
   [X9.62], NIST [FIPS-186-2] and SECG [SEC2].

その上、相互運用性を奨励するために、実装SHOULDはANSI[X9.62]、NIST[FIPS-186-2]、およびSECG[SEC2]によって指定された楕円曲線ドメインパラメタを使用します。

6  Certificates using ECC

ECCを使用する6通の証明書

   Internet X.509 certificates [PKI] can be used in conjunction with
   this specification to distribute agents' public keys.  The use of ECC
   algorithms and keys within X.509 certificates is specified in [PKI-
   ALG].

エージェントの公開鍵を分配するのに、この仕様に関連してインターネットX.509証明書[PKI]を使用できます。 X.509証明書の中のECCアルゴリズムとキーの使用は[PKI- ALG]で指定されます。

7  SMIMECapabilities Attribute and ECC

7のSMIMECapabilities属性とECC

   A sending agent MAY announce to receiving agents that it supports one
   or more of the ECC algorithms in this document by using the
   SMIMECapabilities signed attribute [MSG, Section 2.5.2].

送付エージェントは、本書では属性[MSG、セクション2.5.2]であると署名されるSMIMECapabilitiesを使用することによってECCアルゴリズムの1つ以上をサポートするとエージェントを受けるのに発表するかもしれません。

   The SMIMECapability value to indicate support for the ECDSA signature
   algorithm is the SEQUENCE with the capabilityID field containing the
   object identifier ecdsa-with-SHA1 with NULL parameters.  The DER
   encoding is:

ECDSA署名アルゴリズムのサポートを示すSMIMECapability値はcapabilityID分野がNULLパラメタでSHA1とオブジェクト識別子ecdsaを含んでいるSEQUENCEです。 DERコード化は以下の通りです。

      30 0b 06 07  2a 86 48 ce   3d 04 01 05  00

30 0b06 07 2a86 48Ce3d04 01 05 00

   The SMIMECapability capabilityID object identifiers for the supported
   key agreement algorithms in this document are dhSinglePass-stdDH-
   sha1kdf-scheme, dhSinglePass-cofactorDH-sha1kdf-scheme, and
   mqvSinglePass-sha1kdf-scheme.  For each of these SMIMECapability
   SEQUENCEs, the parameters field is present and indicates the
   supported key-encryption algorithm with the KeyWrapAlgorithm
   algorithm identifier.  The DER encodings that indicate capability of
   the three key agreement algorithms with CMS Triple-DES key wrap are:

サポートしている主要な協定アルゴリズムのためのSMIMECapability capabilityIDオブジェクト識別子は、本書ではdhSinglePass-stdDH- sha1kdf-体系と、dhSinglePass-cofactorDH-sha1kdf-体系と、mqvSinglePass-sha1kdf-体系です。 それぞれのこれらのSMIMECapability SEQUENCEs、分野が存在していて、サポートしている主要な暗号化アルゴリズムを示すパラメタ、KeyWrapAlgorithmアルゴリズム識別子。 CMS Triple-DESの主要な包装で3つの主要な協定アルゴリズムの能力を示すDER encodingsは以下の通りです。

      30 1c 06 09  2b 81 05 10   86 48 3f 00  02 30 0f 06
      0b 2a 86 48  86 f7 0d 01   09 10 03 06  05 00

30 1c06 09 2b81 05 10 86 48 3f00 02 30 0f06 0b 2a86 48 86f7 0d01 09 10 03 06 05 00

   for ephemeral-static ECDH,

はかなく静的なECDHのために

Blake-Wilson, et al.         Informational                      [Page 9]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[9ページ]のRFC3278使用

      30 1c 06 09  2b 81 05 10   86 48 3f 00  03 30 0f 06
      0b 2a 86 48  86 f7 0d 01   09 10 03 06  05 00

30 1c06 09 2b81 05 10 86 48 3f00 03 30 0f06 0b 2a86 48 86f7 0d01 09 10 03 06 05 00

   for ephemeral-static ECDH with cofactor method, and

そして補助因子メソッドがあるはかなく静的なECDHのために。

      30 1c 06 09  2b 81 05 10   86 48 3f 00  10 30 0f 06
      0b 2a 86 48  86 f7 0d 01   09 10 03 06  05 00

30 1c06 09 2b81 05 10 86 48 3f00 10 30 0f06 0b 2a86 48 86f7 0d01 09 10 03 06 05 00

   for ECMQV.

ECMQVのために。

8  ASN.1 Syntax

8 ASN.1構文

   The ASN.1 syntax used in this document is gathered in this section
   for reference purposes.

本書では使用されるASN.1構文は参照目的のためにこのセクションに集められます。

8.1  Algorithm identifiers

8.1 アルゴリズム識別子

   The algorithm identifiers used in this document are taken from
   [X9.62], [SEC1] and [SEC2].

[X9.62]、[SEC1]、および[SEC2]から本書では使用されるアルゴリズム識別子を取ります。

   The following object identifier indicates the hash algorithm used in
   this document:

以下のオブジェクト識別子は本書では使用されるハッシュアルゴリズムを示します:

      sha-1 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
         oiw(14) secsig(3) algorithm(2) 26 }

sha-1 OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)oiw(14) secsig(3)アルゴリズム(2)26

   The following object identifier is used in this document to indicate
   an elliptic curve public key:

以下のオブジェクト識別子は楕円曲線公開鍵を示すのに本書では使用されます:

      id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-x9-62 keyType(2) 1 }

イド-ecPublicKeyオブジェクト識別子:、:= ansi-x9-62 keyType(2)1

   where

どこ

      ansi-x9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
        10045 }

ansi-x9-62 OBJECT IDENTIFIER:、:= iso(1)は(2) 私たち(840)10045をメンバーと同じくらい具体化させます。

   When the object identifier id-ecPublicKey is used here with an
   algorithm identifier, the associated parameters contain NULL.

オブジェクト識別子イド-ecPublicKeyがアルゴリズム識別子と共にここで使用されるとき、関連パラメタはNULLを含んでいます。

   The following object identifier indicates the digital signature
   algorithm used in this document:

以下のオブジェクト識別子は本書では使用されるデジタル署名アルゴリズムを示します:

      ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { ansi-x9-62 signatures(4)
         1 }

SHA1とecdsaオブジェクト識別子:、:= ansi-x9-62署名(4)1

Blake-Wilson, et al.         Informational                     [Page 10]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[10ページ]のRFC3278使用

   When the object identifier ecdsa-with-SHA1 is used within an
   algorithm identifier, the associated parameters field contains NULL.

SHA1とオブジェクト識別子ecdsaがアルゴリズム識別子の中で使用されるとき、関連パラメタ分野はNULLを含んでいます。

   The following object identifiers indicate the key agreement
   algorithms used in this document:

以下のオブジェクト識別子は本書では使用される主要な協定アルゴリズムを示します:

      dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
         x9-63-scheme 2}

dhSinglePass-stdDH-sha1kdf-体系オブジェクト識別子:、:= x9 63体系2

      dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
         x9-63-scheme 3}

dhSinglePass-cofactorDH-sha1kdf-体系オブジェクト識別子:、:= x9 63体系3

      mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= {
         x9-63-scheme 16}

mqvSinglePass-sha1kdf-体系オブジェクト識別子:、:= x9 63体系16

   where

どこ

      x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) tc68(133) country(16) x9(840)
         x9-63(63) schemes(0) }

x9 63体系OBJECT IDENTIFIER:、:= iso(1)の特定された組織(3)tc68(133)の国(16)x9(840) x9-63(63)体系(0)

   When the object identifiers are used here within an algorithm
   identifier, the associated parameters field contains the CMS
   KeyWrapAlgorithm algorithm identifier.

オブジェクト識別子がアルゴリズム識別子の中でここで使用されるとき、関連パラメタ分野はCMS KeyWrapAlgorithmアルゴリズム識別子を含んでいます。

8.2  Other syntax

8.2 他の構文

   The following additional syntax is used here.

以下の追加構文はここで使用されます。

   When using ECDSA with SignedData, ECDSA signatures are encoded using
   the type:

SignedDataとECDSAを使用するとき、ECDSA署名はタイプを使用することでコード化されます:

      ECDSA-Sig-Value ::= SEQUENCE {
         r INTEGER,
         s INTEGER }

以下をECDSA-Sig評価してください:= 系列r整数、s整数

   ECDSA-Sig-Value is specified in [X9.62].  Within CMS, ECDSA-Sig-Value
   is DER-encoded and placed within a signature field of SignedData.

ECDSA-Sig-値は[X9.62]で指定されます。 CMSの中では、ECDSA-Sig-値は、DERによってコード化されてSignedDataの署名分野の中に置かれます。

   When using ECDH and ECMQV with EnvelopedData and AuthenticatedData,
   ephemeral and static public keys are encoded using the type ECPoint.

EnvelopedDataとAuthenticatedDataとECDHとECMQVを使用するとき、はかなくて静的な公開鍵は、タイプECPointを使用することでコード化されます。

      ECPoint ::= OCTET STRING

ECPoint:、:= 八重奏ストリング

   When using ECMQV with EnvelopedData and AuthenticatedData, the
   sending agent's ephemeral public key and additional keying material
   are encoded using the type:

EnvelopedDataとAuthenticatedDataとECMQVを使用するとき、送付エージェントのはかない公開鍵と追加合わせることの材料はタイプを使用することでコード化されます:

Blake-Wilson, et al.         Informational                     [Page 11]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[11ページ]のRFC3278使用

      MQVuserKeyingMaterial ::= SEQUENCE {
         ephemeralPublicKey OriginatorPublicKey,
         addedukm [0] EXPLICIT UserKeyingMaterial OPTIONAL  }

MQVuserKeyingMaterial:、:= 系列ephemeralPublicKey OriginatorPublicKey、addedukm[0]EXPLICIT UserKeyingMaterial OPTIONAL

   The ECPoint syntax in used to represent the ephemeral public key and
   placed in the ephemeralPublicKey field.  The additional user keying
   material is placed in the addedukm field.  Then the
   MQVuserKeyingMaterial value is DER-encoded and placed within a ukm
   field of EnvelopedData or AuthenticatedData.

はかない公開鍵を表すのにおいて中古であってephemeralPublicKey分野に置かれるところのECPoint構文。 材料を合わせる追加ユーザはaddedukm分野に置かれます。 次に、MQVuserKeyingMaterial値は、DERによってコード化されてEnvelopedDataかAuthenticatedDataのukm分野の中に置かれます。

   When using ECDH or ECMQV with EnvelopedData or AuthenticatedData, the
   key-encryption keys are derived by using the type:

EnvelopedDataかAuthenticatedDataとECDHかECMQVを使用するとき、主要な暗号化キーはタイプを使用することによって、引き出されます:

      ECC-CMS-SharedInfo ::= SEQUENCE {
         keyInfo AlgorithmIdentifier,
         entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
         suppPubInfo [2] EXPLICIT OCTET STRING   }

ECC cm SharedInfo:、:= 系列keyInfo AlgorithmIdentifier、entityUInfoの明白な八重奏ストリング任意の、そして、suppPubInfo[2]明白な八重奏[0]ストリング

   The fields of ECC-CMS-SharedInfo are as follows:

ECC-CMS-SharedInfoの分野は以下の通りです:

      keyInfo contains the object identifier of the key-encryption
      algorithm (used to wrap the CEK) and NULL parameters.

keyInfoは主要な暗号化アルゴリズム(以前はよくCEKを包装していた)とNULLパラメタに関する物の識別子を含んでいます。

      entityUInfo optionally contains additional keying material
      supplied by the sending agent.  When used with ECDH and CMS, the
      entityUInfo field contains the octet string ukm.  When used with
      ECMQV and CMS, the entityUInfo contains the octet string addedukm
      (encoded in MQVuserKeyingMaterial).

entityUInfoは任意に材料が送付エージェントから供給した追加合わせることを含んでいます。 ECDHとCMSと共に使用されると、entityUInfo分野は八重奏ストリングukmを含んでいます。 ECMQVとCMSと共に使用されると、entityUInfoは八重奏ストリングaddedukm(MQVuserKeyingMaterialでは、コード化される)を含んでいます。

      suppPubInfo contains the length of the generated KEK, in bits,
      represented as a 32 bit number, as in [CMS-DH].  (E.g. for 3DES it
      would be 00 00 00 c0.)

suppPubInfoは[CMS-DH]のように32ビットの数として表されたビットに発生しているKEKの長さを含んでいます。 (例えば、3DESに関して、それは00 00 00c0でしょう。)

   Within CMS, ECC-CMS-SharedInfo is DER-encoded and used as input to
   the key derivation function, as specified in [SEC1, Section 3.6.1].
   Note that ECC-CMS-SharedInfo differs from the OtherInfo specified in
   [CMS-DH].  Here, a counter value is not included in the keyInfo field
   because the key derivation function specified in [SEC1, Section
   3.6.1] ensures that sufficient keying data is provided.

CMSの中では、ECC-CMS-SharedInfoはDERによってコード化されています、そして、入力されるように使用されて、主要な派生に、[SEC1、セクション3.6.1]は指定されるように機能します。 ECC-CMS-SharedInfoが[CMS-DH]で指定されたOtherInfoと異なっていることに注意してください。 ここに、指定された主要な派生機能が、十分な合わせるデータが提供されるのを確実にするので[SEC1、セクション3.6.1]、対価はkeyInfo分野に含まれていません。

9  Summary

9概要

   This document specifies how to use ECC algorithms with the S/MIME
   CMS.  Use of ECC algorithm within CMS can result in reduced
   processing requirements for S/MIME agents, and reduced bandwidth for
   CMS messages.

このドキュメントはS/MIME CMSと共にECCアルゴリズムを使用する方法を指定します。CMSの中のECCアルゴリズムの使用はS/MIMEエージェントのための減少している処理所要、およびCMSメッセージのための減少している帯域幅をもたらすことができます。

Blake-Wilson, et al.         Informational                     [Page 12]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[12ページ]のRFC3278使用

References

参照

   [X9.62]      ANSI X9.62-1998, "Public Key Cryptography For The
                Financial Services Industry: The Elliptic Curve Digital
                Signature Algorithm (ECDSA)", American National
                Standards Institute, 1999.

[X9.62]ANSI X9.62-1998、「財政的のための公開鍵暗号は産業にサービスを提供します」。 「楕円曲線デジタル署名アルゴリズム(ECDSA)」、American National Standards Institut、1999。

   [PKI-ALG]    Bassham, L., Housley R. and W. Polk, "Algorithms and
                Identifiers for the Internet X.509 Public Key
                Infrastructure Certificate and CRL Profile", RFC 3279,
                April 2002.

[PKI-ALG] Bassham、L.、Housley R.、W.ポーク、および「インターネットX.509公開鍵暗号基盤証明書とCRLプロフィールのためのアルゴリズムと識別子」、RFC3279(2002年4月)

   [BON]        D. Boneh, "The Security of Multicast MAC", Presentation
                at Selected Areas of Cryptography 2000, Center for
                Applied Cryptographic Research, University of Waterloo,
                2000.  Paper version available from
                http://crypto.stanford.edu/~dabo/papers/mmac.ps

Boneh(「マルチキャストMACのセキュリティ」、暗号2000の選択された領域でのプレゼンテーション)が適用された暗号の研究、ウォータールー大学、2000年のために中心に置く[BON]D.。 http://crypto.stanford.edu/~dabo/papers/mmac.ps から利用可能な紙のバージョン

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

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

   [FIPS-180]   FIPS 180-1, "Secure Hash Standard", National Institute
                of Standards and Technology, April 17, 1995.

[FIPS-180]FIPS180-1、「安全な細切れ肉料理規格」、米国商務省標準技術局、1995年4月17日。

   [FIPS-186-2] FIPS 186-2, "Digital Signature Standard", National
                Institute of Standards and Technology, 15 February 2000.

[FIPS-186-2]FIPS186-2、「デジタル署名基準」、米国商務省標準技術局、2000年2月15日。

   [PKI]        Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
                X.509 Public Key Infrastructure Certificate and
                Certificate Revocation List (CRL) Profile", RFC 3280,
                April 2002.

[PKI] HousleyとR.とポークとW.とフォードとW.と一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280、2002年4月。

   [CMS]        Housley, R., "Cryptographic Message Syntax", RFC 2630,
                June 1999.

[cm] Housley、R.、「暗号のメッセージ構文」、RFC2630、1999年6月。

   [IEEE1363]   IEEE P1363, "Standard Specifications for Public Key
                Cryptography", Institute of Electrical and Electronics
                Engineers, 2000.

[IEEE1363]IEEE P1363、「公開鍵暗号のための標準の仕様」、米国電気電子技術者学会、2000。

   [K]          B. Kaliski, "MQV Vulnerabilty", Posting to ANSI X9F1 and
                IEEE P1363 newsgroups, 1998.

[K]B.Kaliski、"MQV Vulnerabilty"、ANSI X9F1とIEEE P1363ニュースグループへのPosting、1998。

   [LMQSV]      L. Law, A. Menezes, M. Qu, J. Solinas and S. Vanstone,
                "An efficient protocol for authenticated key agreement",
                Technical report CORR 98-05, University of Waterloo,
                1998.

[LMQSV] L.法とA.メネゼスとM.QuとJ.SolinasとS.Vanstone、「認証された主要な協定のための効率的なプロトコル」、TechnicalはCORR98-05、ウォータールー大学、1998を報告します。

Blake-Wilson, et al.         Informational                     [Page 13]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[13ページ]のRFC3278使用

   [CMS-KEA]    Pawling, J., "CMS KEA and SKIPJACK Conventions", RFC
                2876, July 2000.

[cmケア] Pawling、J.、「cmケアとトビウオの類コンベンション」、RFC2876、2000年7月。

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

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

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

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

   [SEC1]       SECG, "Elliptic Curve Cryptography", Standards for
                Efficient Cryptography Group, 2000. Available from
                www.secg.org/collateral/sec1.pdf.

[SEC1]SECG、「楕円曲線暗号」、効率的な暗号グループ、2000年の規格。 www.secg.org/傍系親族/sec1.pdfから、利用可能です。

   [SEC2]       SECG, "Recommended Elliptic Curve Domain Parameters",
                Standards for Efficient Cryptography Group, 2000.
                Available from www.secg.org/collateral/sec2.pdf.

[SEC2]SECG、「お勧めの楕円曲線ドメインパラメタ」、効率的な暗号グループ、2000年の規格。 www.secg.org/傍系親族/sec2.pdfから、利用可能です。

Security Considerations

セキュリティ問題

   This specification is based on [CMS], [X9.62] and [SEC1] and the
   appropriate security considerations of those documents apply.

この仕様は[CMS]、[X9.62]、および[SEC1]に基づいています、そして、それらのドキュメントの適切なセキュリティ問題は適用されます。

   In addition, implementors of AuthenticatedData should be aware of the
   concerns expressed in [BON] when using AuthenticatedData to send
   messages to more than one recipient.  Also, users of MQV should be
   aware of the vulnerability in [K].

さらに、AuthenticatedDataの作成者は1人以上の受取人にメッセージを送るのにAuthenticatedDataを使用するとき[BON]に述べられた関心を意識しているべきです。 また、MQVのユーザも[K]で脆弱性を意識しているべきです。

   When 256, 384, and 512 bit hash functions succeed SHA-1 in future
   revisions of [FIPS], [FIPS-186-2], [X9.62] and [SEC1], then they can
   similarly succeed SHA-1 in a future revision of this document.

256、384、および512ビットのハッシュ関数が[FIPS]、[FIPS-186-2]、[X9.62]、および[SEC1]の今後の改正でSHA-1を引き継ぐと、彼らはこのドキュメントの今後の改正で同様にSHA-1を引き継ぐことができます。

Intellectual Property Rights

知的所有権

   The IETF has been notified of intellectual property rights claimed in
   regard to the specification contained in this document.  For more
   information, consult the online list of claimed rights
   (http://www.ietf.org/ipr.html).

IETFは本書では含まれた仕様に関して要求された知的所有権について通知されました。 詳しくは、要求された権利( http://www.ietf.org/ipr.html )のオンラインリストに相談してください。

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to

IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証か、された試みの結果もコピーされます。

Blake-Wilson, et al.         Informational                     [Page 14]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[14ページ]のRFC3278使用

   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

作成者によるそのような所有権の使用に一般的なライセンスか許可を得てください。さもないと、IETF事務局からこの仕様のユーザを得ることができます。

Acknowledgments

承認

   The methods described in this document are based on work done by the
   ANSI X9F1 working group.  The authors wish to extend their thanks to
   ANSI X9F1 for their assistance.  The authors also wish to thank Peter
   de Rooij for his patient assistance.  The technical comments of
   Francois Rousseau were valuable contributions.

本書では説明された方法はANSI X9F1ワーキンググループによって行われた仕事に基づいています。 作者は彼らの支援のためにANSI X9F1に感謝したがっています。 また、作者は彼の我慢強い支援についてピーターde Rooijに感謝したがっています。 フランソア・ルソーの技術的なコメントは有価約因でした。

Authors' Addresses

作者のアドレス

   Simon Blake-Wilson
   Certicom Corp
   5520 Explorer Drive #400
   Mississauga, ON L4W 5L1

L4W 5L1の上のサイモンブレーク-ウィルソンCerticom Corp5520Explorerドライブ#400ミシソーガ

   EMail: sblakewi@certicom.com

メール: sblakewi@certicom.com

   Daniel R. L. Brown
   pCerticom Corp
   5520 Explorer Drive #400
   Mississauga, ON L4W 5L1

L4W 5L1の上のダニエルR.L.ブラウンpCerticom Corp5520Explorerドライブ#400ミシソーガ

   EMail: dbrown@certicom.com

メール: dbrown@certicom.com

   Paul Lambert

ポール・ランバート

   EMail: plambert@sprintmail.com

メール: plambert@sprintmail.com

Blake-Wilson, et al.         Informational                     [Page 15]

RFC 3278              Use of ECC Algorithms in CMS            April 2002

ブレーク-ウィルソン、他 cm2002年4月のECCアルゴリズムの情報[15ページ]のRFC3278使用

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Blake-Wilson, et al.         Informational                     [Page 16]

ブレーク-ウィルソン、他 情報[16ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

PHPでwhois検索をする Net_Whois

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る