RFC 3278 - Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3278
タイトル : RFC 3278 - 暗号メッセージ構文（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用
翻訳編集 : 自動生成

[要約] RFC 3278は、暗号メッセージ構文（CMS）で楕円曲線暗号（ECC）アルゴリズムを使用するためのガイドラインです。このRFCの目的は、CMSでECCを効果的に利用するための手法とベストプラクティスを提供することです。

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

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

暗号メッセージ構文（CMS）での楕円曲線暗号（ECC）アルゴリズムの使用

Status of this Memo

本文書の状態

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

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

著作権表示

Abstract

概要

This document describes 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.

このドキュメントでは、暗号メッセージ構文（CMS）で楕円曲線暗号（ECC）公開鍵アルゴリズムを使用する方法について説明します。 ECCアルゴリズムは、デジタル署名の作成とコンテンツの暗号化または認証のための鍵の交換をサポートしています。アルゴリズム処理の定義は、ANSI X9F1ワーキンググループによって開発されたANSI X9.62標準、IEEE 1363標準、およびSEC 1標準に基づいています。

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

読者の注意は、このドキュメントの最後にある知的財産権のセクションに呼び出されます。

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 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:

暗号化メッセージ構文（CMS）は、暗号化アルゴリズムに依存しません。この仕様は、CMSで楕円曲線暗号（ECC）公開鍵アルゴリズムを使用するためのプロファイルを定義しています。 ECCアルゴリズムは、次のCMSコンテンツタイプに組み込まれています。

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

- コンテンツに署名するためのECCベースのデジタル署名方式（ECDSA）をサポートする「SignedData」

- '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

- コンテンツ認証と整合性に使用されるMACキーを暗号化するペアワイズキー暗号化キーを生成するためのECCベースの公開キー合意方法（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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 BCP 14、RFC 2119 [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で楕円曲線デジタル署名アルゴリズム（ECDSA）を使用する方法について説明します。 ECDSAは[X9.62]で指定されています。この方法は、デジタル署名アルゴリズム（DSA）[FIPS 186-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署名アルゴリズムを識別するアルゴリズム識別子ecdsa-with-SHA1（セクション8.1を参照）が含まれています。

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-Valueの値のDERエンコーディング（オクテット文字列として）を含める必要があります（セクション8.2を参照）。

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公開鍵の証明書が含まれる場合があります。 ECC証明書については、セクション6で説明します。

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:

ECDSAをSignedDataと共に使用する場合、送信エージェントは、[CMS]で指定されているSignedDataのメッセージダイジェスト計算プロセスと署名生成プロセスを使用します。データに署名するために、送信エージェントは、[X9.62、Section 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]は、[CMS、セクション5.4]に従って生成されたメッセージダイジェストを[X9.62、セクション4.3]のデータ変換方法を使用して整数に変換することによって決定されます。 .2]。

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-Value構文（セクション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、Section 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]では、[CMS、セクション5.4]に従って生成されたメッセージダイジェストを[X9.62、セクション4.3]のデータ変換方法を使用して整数に変換することにより、整数「e '」が代わりに決定されます。 .2]。

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

署名を検証するために、受信エージェントは整数rおよびsを受信メッセージのSignerInfo署名フィールドから取得します。

3 EnvelopedData using ECC Algorithms

3 ECCアルゴリズムを使用したEnvelopedData

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

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

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で一時的楕円曲線Diffie-Hellman（ECDH）鍵合意アルゴリズムを使用する方法について説明します。エフェメラルスタティックECDHは、[SEC1]および[IEEE1363]で指定されています。エフェメラルスタティックECDHは、ドキュメント[CMS、セクション12.3.1.1]および[CMS-DH]で共同で指定されたエフェメラルスタティックDiffie-Hellman鍵合意アルゴリズムの楕円曲線アナログです。

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

ECDHとCMS EnvelopedDataをキーアグリーメントで使用する実装では、次の手法と形式を使用する必要があります。

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でephemeral-static 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.

originatorは代替originatorKeyである必要があります。 originatorKeyアルゴリズムフィールドには、NULLパラメータを持つid-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).

keyEncryptionAlgorithmには、標準ECDHプリミティブが使用されている場合はdhSinglePass-stdDH-sha1kdf-schemeオブジェクト識別子（セクション8.1を参照）が含まれていなければならず、補因子ECDHプリミティブが使用されている場合はdhSinglePass-cofactorDH-sha1kdf-schemeオブジェクト識別子（セクション8.1が含まれています）パラメータフィールドには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でephemeral-static ECDHを使用する場合、送信エージェントは最初に受信者のEC公開鍵とドメインパラメータを（たとえば、受信者の証明書から）取得します。次に、送信エージェントは、KeyWrapAlgorithm対称鍵サイズ（ビット単位）である整数「keydatalen」と、ECC-CMS-SharedInfoのDERエンコードであるビット文字列「SharedInfo」を決定します（セクション8.2を参照）。次に、送信エージェントは、[SEC1、セクション6.1]で指定された楕円曲線Diffie-Hellmanスキームのキー展開およびキー合意操作を実行します。その結果、送信エージェントは以下を取得します。

- 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

- ECPointタイプ（セクション8.2を参照）の値として表され、ビット文字列にカプセル化され、KeyAgreeRecipientInfo発信者フィールドに配置された一時公開鍵、および

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

- [CMS]で指定されている、その受信者のペアワイズキー暗号化キーとして使用される共有秘密ビット文字列 "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でephemeral-static ECDHを使用する場合、受信エージェントは、ECC-CMS-SharedInfo（セクション8.2を参照）のDERエンコードであるビット文字列「SharedInfo」と、キーサイズから整数「keydatalen」を決定します。 KeyWrapAlgorithmのビット。受信エージェントは、ビット文字列としてカプセル化されたタイプECPoint（セクション8.2を参照）の値を使用して、ビット文字列KeyAgreeRecipientInfo発信者からエフェメラルEC公開鍵を取得します。受信エージェントは、[SEC1、セクション6.1]で指定された楕円曲線Diffie-Hellmanスキームの鍵合意操作を実行します。その結果、受信エージェントは共有秘密ビットストリング「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.

このセクションでは、1パス楕円曲線MQV（ECMQV）鍵合意アルゴリズムをEnvelopedDataで使用する方法について説明します。 ECMQVは[SEC1]および[IEEE1363]で指定されています。 KEAアルゴリズム[CMS-KEA]と同様に、1-Pass 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.

1-Pass ECMQVとCMS EnvelopedDataをキー合意で使用する実装では、次の手法と形式を使用する必要があります。

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公開鍵を識別します。これは、issuerAndSerialNumberまたはsubjectKeyIdentifierのいずれかであり、送信エージェントの証明書の1つを指す必要があります（SHOULD）。

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

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パラメータフィールドを持つid-ecPublicKeyオブジェクト識別子（セクション8.1を参照）を含める必要があります。 MQVuserKeyingMaterial ephemeralPublicKey publicKeyフィールドには、送信エージェントの一時的なEC公開鍵を表す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はmqvSinglePass-sha1kdf-schemeアルゴリズム識別子（セクション8.1を参照）であり、パラメーターフィールドKeyWrapAlgorithmが必要です。 KeyWrapAlgorithmは、1パスECMQVアルゴリズムを使用して生成されたKEKで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公開鍵とドメインパラメータを（たとえば、受信者の証明書から）取得し、ドメインパラメータが同じであることを確認します。次に、送信エージェントは、KeyWrapAlgorithm対称鍵サイズ（ビット単位）である整数「keydatalen」と、ECC-CMS-SharedInfoのDERエンコードであるビット文字列「SharedInfo」を決定します（セクション8.2を参照）。次に、送信エージェントは、[SEC1、セクション6.2]で指定された楕円曲線MQVスキームのキー展開およびキー合意操作を実行します。その結果、送信エージェントは次のものを取得します。

- 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

- ビット列にカプセル化され、MQVuserKeyingMaterial ephemeralPublicKey publicKeyフィールド（セクション8.2を参照）に配置された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].

- [CMS]で指定されている、その受信者のペアワイズキー暗号化キーとして使用される共有秘密ビット文字列 "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（セクション8.2を参照）のDERエンコードであるビット文字列「SharedInfo」と、キーサイズから整数「keydatalen」を決定します。 KeyWrapAlgorithmのビット。次に、受信エージェントは、3.2.1項で説明されているように、発信者フィールドとukmフィールドから発信者の静的および短命なEC公開鍵を取得し、ridで識別された静的EC公開鍵を取得します。

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.

フィールドとドメインパラメータが同じであることを確認します。次に、受信側エージェントは、楕円曲線MQVスキーム[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フィールドは、このドキュメントのセクション3.2.1の対応する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.

このドキュメントのセクション3.2.2で指定されているように、送信エージェントは1- Pass ECMQVを使用したEnvelopedDataと同じアクションを使用します。

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]に気付かずにコンテンツを変更する攻撃が可能です。このような攻撃に関与する送信エージェントは、受信者ごとに個別のAuthenticatedDataを使用する必要があります（SHOULD）。

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.

受信エージェントは、このドキュメントのセクション3.2.3で指定されているように、1パスECMQVを使用したEnvelopedDataと同じアクションを使用します。

Note: see Note in Section 4.1.2.

注：セクション4.1.2の注を参照してください。

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.

この仕様の実装は、ECDSAを使用したSignedDataまたは一時的静的ECDHを使用したEnvelopedDataのいずれかを実装する必要があります。この仕様の実装は、ECDSAを使用したSignedDataと、一時的静的ECDHを使用したEnvelopedDataの両方を実装する必要があります（SHOULD）。実装は、AuthenticatedDataや1-Pass ECMQVなど、指定された他の手法を実装してもよい（MAY）。

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

さらに、相互運用性を促進するために、実装ではANSI [X9.62]、NIST [FIPS-186-2]、およびSECG [SEC2]で指定された楕円曲線ドメインパラメータを使用する必要があります（SHOULD）。

6 Certificates using ECC

6 ECCを使用した証明書

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

送信エージェントは、SMIMECapabilities署名属性[MSG、セクション2.5.2]を使用して、このドキュメントの1つまたは複数のECCアルゴリズムをサポートすることを受信エージェントに通知してもよい（MAY）。

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値は、NULLパラメータを持つオブジェクト識別子ecdsa-with-SHA1を含むcapabilityIDフィールドを持つSEQUENCEです。 DERエンコードは次のとおりです。

30 0b 06 07 2a 86 48 ce 3d 04 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-scheme、dhSinglePass-cofactorDH-sha1kdf-scheme、およびmqvSinglePass-sha1kdf-schemeです。これらの各SMIMECapability SEQUENCEについて、parametersフィールドが存在し、KeyWrapAlgorithmアルゴリズム識別子を使用してサポートされている鍵暗号化アルゴリズムを示します。 CMS Triple-DESキーラップを使用した3つのキー合意アルゴリズムの機能を示すDERエンコーディングは次のとおりです。

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

for ephemeral-static ECDH,

一時的な静的ECDHの場合、

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

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

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 }

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 }

where

ただし

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

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

ここでオブジェクト識別子id-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 }

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

オブジェクト識別子ecdsa-with-SHA1がアルゴリズム識別子内で使用される場合、関連するパラメーターフィールドには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-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= {
         x9-63-scheme 3}

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

where

ただし

      x9-63-scheme OBJECT IDENTIFIER ::= { iso(1)
         identified-organization(3) tc68(133) country(16) x9(840)
         x9-63(63) schemes(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:

ECDSAをSignedDataと共に使用する場合、ECDSA署名は次のタイプを使用してエンコードされます。

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

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-Valueは、[X9.62]で指定されています。 CMS内では、ECDSA-Sig-Valueは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

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を使用する場合、送信エージェントの一時的な公開鍵と追加の鍵情報は、次のタイプを使用してエンコードされます。

      MQVuserKeyingMaterial ::= SEQUENCE {
         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.

ECPoint構文は、一時的な公開鍵を表すために使用され、ephemeralPublicKeyフィールドに配置されます。追加のユーザーキーイングマテリアルは、adddedkmフィールドに配置されます。次に、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   }

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]のように、生成されたKEKの長さがビット単位で、32ビット数として表されます。（たとえば、3DESの場合は00 00 00 c0になります。）

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メッセージの帯域幅が減少する可能性があります。

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）」、米国規格協会、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. and W. Polk、 "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and CRL Profile"、RFC 3279、April 2002。

   [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

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

[必須] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

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

[FIPS-180] FIPS 180-1、「Secure Hash Standard」、国立標準技術研究所、1995年4月17日。

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

[FIPS-186-2] FIPS 186-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.、Polk、W.、Ford、W。およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年4月。

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

[CMS] Housley、R。、「Cryptographic Message Syntax」、RFC 2630、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.カリスキー、「MQVの脆弱性」、ANSI X9F1およびIEEE P1363ニュースグループへの投稿、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. Law、A。Menezes、M。Qu、J。SolinasおよびS. Vanstone、「認証された鍵合意のための効率的なプロトコル」、テクニカルレポートCORR 98-05、ウォータールー大学、1998年。

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

[CMS-KEA] Pawling、J。、「CMS KEA and SKIPJACK Conventions」、RFC 2876、2000年7月。

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

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

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

[CMS-DH] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、1999年6月。

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

[SEC1] SECG、「Elliptic Curve Cryptography」、Standards for Efficient Cryptography Group、2000。www.secg.org/ collateral / 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/ collateral / 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の実装者は、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.

[FIPS]、[FIPS-186-2]、[X9.62]、および[SEC1]の将来のリビジョンで256、384、および512ビットのハッシュ関数が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 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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP 11にあります。公開のために利用可能にされた権利の主張のコピー、および利用可能になるライセンスの保証、または試行の結果この仕様の実装者またはユーザーがそのような所有権を使用するための一般的なライセンスまたは許可を取得するために作成されたものは、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の支援に感謝します。著者はまた、彼の忍耐強い援助のためにピーター・デ・ルーイに感謝したいと思います。フランソワ・ルソーの技術的なコメントは貴重な貢献でした。

Authors' Addresses

著者のアドレス

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

Simon Blake-Wilson Certicom Corp 5520 Explorer Drive＃400ミシサガ、ON L4W 5L1

   EMail: sblakewi@certicom.com

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

ダニエルR. L.ブラウンpCerticom Corp 5520 Explorer Drive＃400ミシサガ、ON L4W 5L1

   EMail: dbrown@certicom.com

Paul Lambert

ポール・ランバート

   EMail: plambert@sprintmail.com

Full Copyright Statement

完全な著作権表示

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する派生物を、全体または一部を問わず、準備、コピー、公開、配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。

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

このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。

Acknowledgement

謝辞

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

RFC Editor機能への資金提供は、現在Internet Societyから提供されています。