[要約] RFC 6278は、Cryptographic Message Syntax (CMS) でのStatic-Static Elliptic Curve Diffie-Hellman (ECDH) 鍵合意の使用に関する文書です。このRFCの目的は、セキュリティの強化を図るために、CMSでのECDH鍵合意のプロセスを標準化することにあります。利用場面としては、電子メールの暗号化、デジタル署名、その他のセキュアな通信が挙げられます。関連するRFCには、RFC 5652（Cryptographic Message Syntax (CMS)）、RFC 6090（Fundamental Elliptic Curve Cryptography Algorithms）、およびRFC 5289（TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode）などがあります。これらの文書と合わせて、RFC 6278は安全な通信プロトコルの実装において重要な役割を果たします。
Internet Engineering Task Force (IETF) J. Herzog
Request for Comments: 6278 R. Khazan
Category: Informational MIT Lincoln Laboratory
ISSN: 2070-1721 June 2011
Use of Static-Static Elliptic Curve Diffie-Hellman Key Agreement in Cryptographic Message Syntax
暗号メッセージ構文での静的-静的楕円曲線Diffie-Hellman鍵合意の使用
Abstract
概要
This document describes how to use the 'static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman where both participants use static Diffie-Hellman values) with the Cryptographic Message Syntax. In this form of key agreement, the Diffie-Hellman values of both the sender and receiver are long-term values contained in certificates.
このドキュメントでは、「静的静的楕円曲線Diffie-Hellman鍵合意方式（つまり、両方の参加者が静的Diffie-Hellman値を使用する楕円曲線Diffie-Hellman）を暗号化メッセージ構文で使用する方法について説明します。この形式の鍵合意では、送信者と受信者の両方のDiffie-Hellman値は、証明書に含まれる長期的な値です。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6278.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6278で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents
このドキュメントは、BCP 78およびIETFドキュメントに関連するIETFトラストの法的規定の対象です。
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
（http://trustee.ietf.org/license-info）このドキュメントの発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Requirements Terminology ...................................5
2. EnvelopedData Using Static-Static ECDH ..........................5
2.1. Fields of the KeyAgreeRecipientInfo ........................5
2.2. Actions of the Sending Agent ...............................6
2.3. Actions of the Receiving Agent .............................7
3. AuthenticatedData Using Static-Static ECDH ......................8
3.1. Fields of the KeyAgreeRecipientInfo ........................8
3.2. Actions of the Sending Agent ...............................8
3.3. Actions of the Receiving Agent .............................9
4. AuthEnvelopedData Using Static-Static ECDH ......................9
4.1. Fields of the KeyAgreeRecipientInfo ........................9
4.2. Actions of the Sending Agent ...............................9
4.3. Actions of the Receiving Agent .............................9
5. Comparison to RFC 5753 ..........................................9
6. Requirements and Recommendations ...............................10
7. Security Considerations ........................................12
8. Acknowledgements ...............................................14
9. References .....................................................14
9.1. Normative References ......................................14
9.2. Informative References ....................................15
This document describes how to use the static-static Elliptic Curve Diffie-Hellman key-agreement scheme (i.e., Elliptic Curve Diffie-Hellman [RFC6090] where both participants use static Diffie-Hellman values) in the Cryptographic Message Syntax (CMS) [RFC5652]. The CMS is a standard notation and representation for cryptographic messages. The CMS uses ASN.1 notation [X.680] [X.681] [X.682] [X.683] to define
このドキュメントでは、暗号メッセージ構文（CMS）[RFC5652で静的静的楕円曲線Diffie-Hellman鍵合意方式（つまり、両方の参加者が静的Diffie-Hellman値を使用する楕円曲線Diffie-Hellman [RFC6090]）を使用する方法について説明します]。 CMSは、暗号メッセージの標準的な表記法および表現です。 CMSはASN.1表記[X.680] [X.681] [X.682] [X.683]を使用して定義します
a number of structures that carry both cryptographically protected information and key-management information regarding the keys used. Of particular interest here are three structures:
暗号で保護された情報と使用される鍵に関する鍵管理情報の両方を運ぶ多くの構造。ここで特に興味深いのは、3つの構造です。
o EnvelopedData, which holds encrypted (but not necessarily authenticated) information [RFC5652],
o EnvelopedData。暗号化された（必ずしも認証されている必要はない）情報を保持します[RFC5652]、
o AuthenticatedData, which holds authenticated (MACed) information [RFC5652], and
o AuthenticatedData。認証済み（MACed）情報を保持します[RFC5652]、および
o AuthEnvelopedData, which holds information protected by authenticated encryption: a cryptographic scheme that combines encryption and authentication [RFC5083].
o AuthEnvelopedData：認証された暗号化によって保護された情報を保持します：暗号化と認証を組み合わせた暗号化スキーム[RFC5083]。
All three of these types share the same basic structure. First, a fresh symmetric key is generated. This symmetric key has a different name that reflects its usage in each of the three structures. EnvelopedData uses a content-encryption key (CEK); AuthenticatedData uses an authentication key; AuthEnvelopedData uses a content-authenticated-encryption key. The originator uses the symmetric key to cryptographically protect the content. The symmetric key is then wrapped for each recipient; only the intended recipient has access to the private keying material necessary to unwrap the symmetric key. Once unwrapped, the recipient uses the symmetric key to decrypt the content, check the authenticity of the content, or both. The CMS supports several different approaches to symmetric key wrapping, including:
これら3つのタイプはすべて同じ基本構造を共有します。最初に、新しい対称鍵が生成されます。この対称鍵には、3つの構造それぞれでの使用法を反映する異なる名前があります。 EnvelopedDataはコンテンツ暗号化キー（CEK）を使用します。 AuthenticatedDataは認証キーを使用します。 AuthEnvelopedDataは、コンテンツ認証された暗号化キーを使用します。発信者は対称鍵を使用して、コンテンツを暗号で保護します。次に、対称鍵が受信者ごとにラップされます。対象の受信者だけが、対称鍵のラップを解除するために必要な秘密鍵情報にアクセスできます。ラップを解除すると、受信者は対称鍵を使用してコンテンツを復号化するか、コンテンツの信頼性を確認するか、またはその両方を行います。 CMSは、対称鍵のラッピングに対するいくつかの異なるアプローチをサポートしています。
o key transport: the symmetric key is encrypted using the public encryption key of some recipient,
o 鍵の転送：対称鍵は、受信者の公開暗号鍵を使用して暗号化されます。
o key-encryption key: the symmetric key is encrypted using a previously distributed symmetric key, and
o キー暗号化キー：対称キーは、以前に配布された対称キーを使用して暗号化されます。
o key agreement: the symmetric key is encrypted using a key-encryption key (KEK) created using a key-agreement scheme and a key-derivation function (KDF).
o 鍵合意：対称鍵は、鍵合意方式と鍵導出関数（KDF）を使用して作成された鍵暗号鍵（KEK）を使用して暗号化されます。
One such key-agreement scheme is the Diffie-Hellman algorithm [RFC2631], which uses group theory to produce a value known only to its two participants. In this case, the participants are the originator and one of the recipients. Each participant produces a private value and a public value, and each participant can produce the shared secret value from their own private value and their counterpart's public value. There are some variations on the basic algorithm: o The basic algorithm typically uses the group 'Z mod p', meaning the set of integers modulo some prime p. One can also use an elliptic curve group, which allows for shorter messages.
そのような鍵合意方式の1つは、Diffie-Hellmanアルゴリズム[RFC2631]です。これは、グループ理論を使用して、2人の参加者だけが知っている値を生成します。この場合、参加者は発信者と受信者の1人です。各参加者はプライベート値とパブリック値を生成し、各参加者は自分のプライベート値と対応するパブリック値から共有秘密値を生成できます。基本的なアルゴリズムにはいくつかのバリエーションがあります。o基本的なアルゴリズムは通常、グループ 'Z mod p'を使用します。これは、素数pを法とする整数のセットを意味します。楕円曲線グループを使用して、メッセージを短くすることもできます。
o Over elliptic curve groups, the standard algorithm can be extended to incorporate the 'cofactor' of the group. This method, called 'cofactor Elliptic Curve Diffie-Hellman' [SP800-56A] can prevent certain attacks possible in the elliptic curve group.
o 楕円曲線グループでは、標準アルゴリズムを拡張して、グループの「補因子」を組み込むことができます。この方法は「補因子楕円曲線ディフィーヘルマン」[SP800-56A]と呼ばれ、楕円曲線グループで発生する可能性のある特定の攻撃を防ぐことができます。
o The participants can generate fresh new public/private values (called ephemeral values) for each run of the algorithm, or they can re-use long-term values (called static values). Ephemeral values add randomness to the resulting private value, while static values can be embedded in certificates. The two participants do not need to use the same kind of value: either participant can use either type. In 'ephemeral-static' Diffie-Hellman, for example, the sender uses an ephemeral public/private pair value while the receiver uses a static pair. In 'static-static' Diffie-Hellman, on the other hand, both participants use static pairs. (Receivers cannot use ephemeral values in this setting, and so we ignore ephemeral-ephemeral and static-ephemeral Diffie-Hellman in this document.)
o 参加者は、アルゴリズムを実行するたびに新しいパブリック/プライベート値（エフェメラル値と呼ばれる）を生成するか、長期値（静的値と呼ばれる）を再利用できます。エフェメラル値は、結果のプライベート値にランダム性を追加しますが、静的な値は証明書に埋め込むことができます。 2人の参加者は同じ種類の値を使用する必要はありません。どちらの参加者もどちらのタイプも使用できます。たとえば、 'ephemeral-static' Diffie-Hellmanでは、送信側は一時的なパブリック/プライベートペアの値を使用し、受信側は静的ペアを使用します。一方、「静的-静的」Diffie-Hellmanでは、両方の参加者が静的ペアを使用します。 （受信者はこの設定でエフェメラル値を使用できないため、このドキュメントではエフェメラルエフェメラルおよびスタティックエフェメラルDiffie-Hellmanを無視します。）
Several of these variations are already described in existing CMS standards; for example, [RFC3370] contains the conventions for using ephemeral-static and static-static Diffie-Hellman over the 'basic' (Z mod p) group. [RFC5753] contains the conventions for using ephemeral-static Diffie-Hellman over elliptic curves (both standard and cofactor methods). It does not, however, contain conventions for using either method of static-static Elliptic Curve Diffie-Hellman, preferring to discuss the Elliptic Curve Menezes-Qu-Vanstone (ECMQV) algorithm instead.
これらのバリエーションのいくつかは、既存のCMS標準ですでに説明されています。たとえば、[RFC3370]には、 'basic'（Z mod p）グループでephemeral-staticおよびstatic-static Diffie-Hellmanを使用するための規則が含まれています。 [RFC5753]には、楕円曲線（標準法と補因子法の両方）でエフェメラルスタティックDiffie-Hellmanを使用するための規則が含まれています。ただし、静的-静的楕円曲線Diffie-Hellmanのいずれかの方法を使用するための規則は含まれておらず、代わりに楕円曲線Menezes-Qu-Vanstone（ECMQV）アルゴリズムについて説明します。
In this document, we specify the conventions for using static-static Elliptic Curve Diffie-Hellman (ECDH) for both standard and cofactor methods. Our motivation stems from the fact that ECMQV has been removed from the National Security Agency's Suite B of cryptographic algorithms and will therefore be unavailable to some participants. These participants can use ephemeral-static Elliptic Curve Diffie-Hellman, of course, but ephemeral-static Diffie-Hellman does not provide source authentication. The CMS does allow the application of digital signatures for source authentication, but this alternative is available only to those participants with certified signature keys. By specifying conventions for static-static Elliptic Curve Diffie-Hellman in this document, we present a third alternative for source authentication, available to those participants with certified Elliptic Curve Diffie-Hellman keys.
このドキュメントでは、標準メソッドと補因子メソッドの両方に静的-静的楕円曲線ディフィーヘルマン（ECDH）を使用するための規則を指定します。私たちの動機は、ECMQVが国家安全保障局の暗号化アルゴリズムスイートBから削除されたため、一部の参加者が利用できないという事実に起因しています。これらの参加者は、エフェメラルスタティック楕円曲線Diffie-Hellmanを使用できますが、エフェメラルスタティックDiffie-Hellmanはソース認証を提供しません。 CMSではソース認証にデジタル署名を適用できますが、この代替手段は、署名キーが認証されている参加者のみが利用できます。このドキュメントで静的-静的楕円曲線Diffie-Hellmanの規則を指定することで、認証された楕円曲線Diffie-Hellmanキーを持つ参加者が利用できるソース認証の3番目の代替方法を示します。
We note that like ephemeral-static ECDH, static-static ECDH creates a secret key shared by the sender and receiver. Unlike ephemeral-static ECDH, however, static-static ECDH uses a static key pair for the sender. Each of the three CMS structures discussed in this document (EnvelopedData, AuthenticatedData, and AuthEnvelopedData) uses static-static ECDH to achieve different goals:
エフェメラルスタティックECDHと同様に、スタティックスタティックECDHは送信者と受信者が共有する秘密鍵を作成することに注意してください。ただし、一時的静的ECDHとは異なり、静的静的ECDHは送信者に静的キーペアを使用します。このドキュメントで説明する3つのCMS構造（EnvelopedData、AuthenticatedData、およびAuthEnvelopedData）はそれぞれ、静的-静的ECDHを使用してさまざまな目標を達成します。
o EnvelopedData uses static-static ECDH to provide data confidentiality. It will not necessarily, however, provide data authenticity.
o EnvelopedDataは静的-静的ECDHを使用してデータの機密性を提供します。ただし、データの信頼性は必ずしも必要ではありません。
o AuthenticatedData uses static-static ECDH to provide data authenticity. It will not provide data confidentiality.
o AuthenticatedDataは静的-静的ECDHを使用してデータの信頼性を提供します。データの機密性は提供されません。
o AuthEnvelopedData uses static-static ECDH to provide both confidentiality and data authenticity.
o AuthEnvelopedDataは、静的-静的ECDHを使用して、機密性とデータの信頼性の両方を提供します。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
If an implementation uses static-static ECDH with the CMS EnvelopedData, then the following techniques and formats MUST be used. The fields of EnvelopedData are as in [RFC5652]; as static-static ECDH is a key-agreement algorithm, the RecipientInfo 'kari' choice is used. When using static-static ECDH, the EnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key.
実装がCMS EnvelopedDataで静的-静的ECDHを使用する場合、次の手法と形式を使用する必要があります。 EnvelopedDataのフィールドは[RFC5652]と同じです。静的静的ECDHは鍵合意アルゴリズムであるため、RecipientInfo 'kari'の選択が使用されます。静的-静的ECDHを使用する場合、EnvelopedData originatorInfoフィールドには、ペアワイズキーの形成に使用されるEC公開キーの証明書を含めることができます（MAY）。
When using static-static ECDH with EnvelopedData, the fields of KeyAgreeRecipientInfo [RFC5652] are as follows:
EnvelopedDataで静的-静的ECDHを使用する場合、KeyAgreeRecipientInfo [RFC5652]のフィールドは次のとおりです。
o version MUST be 3.
o バージョンは3でなければなりません。
o originator identifies the static EC public key of the sender. It MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and it MUST point to one of the sending agent's certificates.
o 発信者は、送信者の静的EC公開鍵を識別します。これは、issuerAndSerialNumberまたはsubjectKeyIdentifierのいずれかである必要があり、送信エージェントの証明書の1つを指す必要があります。
o ukm MAY be present or absent. However, message originators SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. As specified in [RFC5652], implementations MUST support ukm message recipient processing, so interoperability is not a concern if the ukm is present or absent. The use of a fresh value for ukm will ensure that a different key is generated for each message between the same sender and receiver. The ukm, if present, is placed in the entityUInfo field of the ECC-CMS-SharedInfo structure [RFC5753] and therefore used as an input to the key-derivation function.
o ukmがあってもなくてもかまいません。ただし、メッセージの発信者にはukmを含める必要があり（SHOULD）、ukmの値が送信されるメッセージに固有であることを保証する必要があります（SHOULD）。 [RFC5652]で指定されているように、実装はukmメッセージの受信者処理をサポートする必要があるため、ukmが存在する場合も存在しない場合も相互運用性は問題になりません。 ukmに新しい値を使用すると、同じ送信者と受信者の間のメッセージごとに異なるキーが生成されます。 ukmが存在する場合は、ECC-CMS-SharedInfo構造体[RFC5753]のentityUInfoフィールドに配置されるため、鍵導出関数への入力として使用されます。
o keyEncryptionAlgorithm MUST contain the object identifier of the key-encryption algorithm, which in this case is a key-agreement algorithm (see Section 5). 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) and any associated parameters (see Section 5).
o keyEncryptionAlgorithmには、鍵暗号化アルゴリズムのオブジェクト識別子が含まれている必要があります。この場合、鍵暗号化アルゴリズムです（セクション5を参照）。パラメータフィールドにはKeyWrapAlgorithmが含まれます。 KeyWrapAlgorithmは、コンテンツ暗号化キー（CEK）をキー暗号化キー（KEK）と関連パラメータで暗号化するために使用される対称暗号化アルゴリズムを示すアルゴリズム識別子です（セクション5を参照）。
o recipientEncryptedKeys contains an identifier and an encrypted CEK for each recipient. The RecipientEncryptedKey KeyAgreeRecipientIdentifier MUST contain either the issuerAndSerialNumber identifying the recipient's certificate or the RecipientKeyIdentifier containing the subject key identifier from the recipient's certificate. In both cases, the recipient's certificate contains the recipient's static ECDH public key. RecipientEncryptedKey EncryptedKey MUST contain the content-encryption key encrypted with the static-static ECDH-generated pairwise key-encryption key using the algorithm specified by the KeyWrapAlgorithm.
o recipientEncryptedKeysには、各受信者の識別子と暗号化されたCEKが含まれています。 RecipientEncryptedKey KeyAgreeRecipientIdentifierには、受信者の証明書を識別するissuerAndSerialNumberまたは受信者の証明書のサブジェクトキー識別子を含むRecipientKeyIdentifierのいずれかが含まれている必要があります。どちらの場合も、受信者の証明書には、受信者の静的ECDH公開鍵が含まれています。 RecipientEncryptedKey EncryptedKeyには、KeyWrapAlgorithmで指定されたアルゴリズムを使用して、静的-静的ECDH生成のペアワイズキー暗号化キーで暗号化されたコンテンツ暗号化キーを含める必要があります。
When using static-static ECDH with EnvelopedData, the sending agent first obtains the EC public key(s) and domain parameters contained in the recipient's certificate. It MUST confirm the following at least once per recipient-certificate:
EnvelopedDataで静的-静的ECDHを使用する場合、送信エージェントは最初に、受信者の証明書に含まれているEC公開鍵とドメインパラメータを取得します。受信者証明書ごとに少なくとも1回は次のことを確認する必要があります。
o that both certificates (the recipient's certificate and its own) contain public-key values with the same curve parameters, and
o 両方の証明書（受信者の証明書とその証明書）に、同じ曲線パラメーターを持つ公開鍵の値が含まれている。
o that both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm identifiers id-ecPublicKey or id-ecDH [RFC5480]).
o これらの公開キー値の両方がECDHに適切であるとマークされている（つまり、アルゴリズム識別子id-ecPublicKeyまたはid-ecDH [RFC5480]でマークされている）。
The sender then determines whether to use standard or cofactor Diffie-Hellman. After doing so, the sender then determines which hash algorithms to use for the key-derivation function. It then chooses the keyEncryptionAlgorithm value that reflects these choices. It then determines: o an integer "keydatalen", which is the KeyWrapAlgorithm symmetric key size in bits, and
送信者は、標準または補因子Diffie-Hellmanを使用するかどうかを決定します。その後、送信者は、キー導出関数に使用するハッシュアルゴリズムを決定します。次に、これらの選択を反映するkeyEncryptionAlgorithm値を選択します。次に、以下を決定します。oビット単位のKeyWrapAlgorithm対称鍵サイズである整数「keydatalen」、および
o the value of ukm, if used.
o 使用される場合、ukmの値。
The sender then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The sending agent then performs either the Elliptic Curve Diffie-Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The sending agent then applies the simple hash-function construct of [X963] (using the hash algorithm identified in the key-agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the sending agent obtains a shared secret bit string "K", which is used as the pairwise key-encryption key (KEK) to wrap the CEK for that recipient, as specified in [RFC5652].
次に、送信者はECC-CMS-SharedInfoのDERエンコードであるビット文字列「SharedInfo」を決定します（[RFC5753]のセクション7.2を参照）。次に、送信エージェントは、[RFC6090]の楕円曲線Diffie-Hellman操作（標準Diffie-Hellmanの場合）または[SP800-56A]の楕円曲線暗号補因子Diffie-Hellman（ECC CDH）プリミティブ（補因子Diffie-Hellmanの場合）を実行します。 ）。次に、送信エージェントは、[鍵一致アルゴリズムで識別されたハッシュアルゴリズムを使用して] [X963]の単純なハッシュ関数構造をDiffie-Hellman操作の結果とSharedInfo文字列に適用します。 （この構造は[SEC1]のセクション3.6.1でも説明されています。）その結果、送信エージェントは共有秘密ビット文字列「K」を取得します。これは、ペアワイズキー暗号化キー（KEK）として使用され、 [RFC5652]で指定されている、その受信者のCEK。
When using static-static ECDH with EnvelopedData, the receiving agent retrieves keyEncryptionAlgorithm to determine the key-agreement algorithm chosen by the sender, which will identify:
EnvelopedDataで静的静的ECDHを使用する場合、受信エージェントはkeyEncryptionAlgorithmを取得して、送信者が選択した鍵合意アルゴリズムを決定します。
o the domain parameters of the curve used,
o 使用される曲線のドメインパラメータ
o whether standard or cofactor Diffie-Hellman was used, and
o 標準または補因子Diffie-Hellmanが使用されたかどうか、および
o which hash function was used for the KDF.
o KDFに使用されたハッシュ関数。
The receiver then retrieves the sender's certificate identified in the rid field and extracts the EC public key(s) and domain parameters contained therein. It MUST confirm the following at least once per sender certificate:
次に、受信者はridフィールドで識別された送信者の証明書を取得し、そこに含まれるEC公開鍵とドメインパラメータを抽出します。送信者の証明書ごとに少なくとも1回は以下を確認する必要があります。
o that both certificates (the sender's certificate and its own) contain public-key values with the same curve parameters, and
o 両方の証明書（送信者の証明書と独自の証明書）に、同じ曲線パラメーターを持つ公開鍵の値が含まれている。
o that both of these public-key values are marked as appropriate for ECDH (that is, marked with algorithm identifiers id-ecPublicKey or id-ecDH [RFC5480]).
o これらの公開キー値の両方がECDHに適切であるとマークされている（つまり、アルゴリズム識別子id-ecPublicKeyまたはid-ecDH [RFC5480]でマークされている）。
The receiver then determines whether standard or cofactor Diffie-Hellman was used. The receiver then determines a bit string "SharedInfo", which is the DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]). The receiving agent then performs either the Elliptic Curve Diffie-Hellman operation of [RFC6090] (for standard Diffie-Hellman) or the Elliptic Curve Cryptography Cofactor Diffie-Hellman (ECC CDH) Primitive of [SP800-56A] (for cofactor Diffie-Hellman). The receiving agent then applies the simple hash-function construct of [X963] (using the hash algorithm identified in the key-agreement algorithm) to the results of the Diffie-Hellman operation and the SharedInfo string. (This construct is also described in Section 3.6.1 of [SEC1].) As a result, the receiving agent obtains a shared secret bit string "K", which it uses as the pairwise key-encryption key to unwrap the CEK.
次に、レシーバーは、標準または補因子のDiffie-Hellmanが使用されたかどうかを判別します。次に、レシーバーはECC-CMS-SharedInfoのDERエンコードであるビット文字列「SharedInfo」を決定します（[RFC5753]のセクション7.2を参照）。次に、受信エージェントは、[RFC6090]の楕円曲線Diffie-Hellman操作（標準Diffie-Hellmanの場合）または[SP800-56A]の楕円曲線暗号補因子Diffie-Hellman（ECC CDH）プリミティブ（補因子Diffie-Hellmanの場合）を実行します。 ）。次に、受信エージェントは、[X963]の単純なハッシュ関数構造を（鍵一致アルゴリズムで識別されたハッシュアルゴリズムを使用して）Diffie-Hellman操作の結果とSharedInfo文字列に適用します。 （この構成体は、[SEC1]のセクション3.6.1でも説明されています。）その結果、受信エージェントは共有秘密ビット文字列 "K"を取得し、ペアワイズキー暗号化キーとして使用してCEKをアンラップします。
This section describes how to use the static-static ECDH key-agreement algorithm with AuthenticatedData. When using static-static ECDH with AuthenticatedData, the fields of AuthenticatedData are as in [RFC5652], but with the following restrictions:
このセクションでは、AuthenticatedDataで静的-静的ECDH鍵合意アルゴリズムを使用する方法について説明します。 AuthenticatedDataで静的-静的ECDHを使用する場合、AuthenticatedDataのフィールドは[RFC5652]と同じですが、次の制限があります。
o macAlgorithm MUST contain the algorithm identifier of the message authentication code (MAC) algorithm. This algorithm SHOULD be one of the following -- id-hmacWITHSHA224, id-hmacWITHSHA256, id-hmacWITHSHA384, or id-hmacWITHSHA512 -- and SHOULD NOT be hmac-SHA1. (See Section 5.)
o macAlgorithmには、メッセージ認証コード（MAC）アルゴリズムのアルゴリズム識別子が含まれている必要があります。このアルゴリズムは、id-hmacWITHSHA224、id-hmacWITHSHA256、id-hmacWITHSHA384、またはid-hmacWITHSHA512のいずれかである必要があり（SHOULD）、hmac-SHA1であってはなりません（SHOULD NOT）。 （セクション5を参照。）
o digestAlgorithm MUST contain the algorithm identifier of the hash algorithm. This algorithm SHOULD be one of the following -- id-sha224, id-sha256, id-sha384, or id-sha512 -- and SHOULD NOT be id-sha1. (See Section 5.)
o digestAlgorithmには、ハッシュアルゴリズムのアルゴリズム識別子が含まれている必要があります。このアルゴリズムは、id-sha224、id-sha256、id-sha384、id-sha512のいずれかである必要があり（SHOULD）、id-sha1であってはなりません（SHOULD NOT）。 （セクション5を参照。）
As static-static ECDH is a key-agreement algorithm, the RecipientInfo kari choice is used in the AuthenticatedData. When using static-static ECDH, the AuthenticatedData originatorInfo field MAY include the certificate(s) for the EC public key(s) used in the formation of the pairwise key.
静的静的ECDHは鍵合意アルゴリズムであるため、AuthenticatedDataではRecipientInfo kariの選択が使用されます。 static-static ECDHを使用する場合、AuthenticatedData originatorInfoフィールドには、ペアワイズキーの形成に使用されるEC公開キーの証明書を含めることができます（MAY）。
The AuthenticatedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The authentication key is wrapped in the same manner as is described there for the content-encryption key.
AuthenticatedData KeyAgreeRecipientInfoフィールドは、このドキュメントのセクション2.1の対応するEnvelopedData KeyAgreeRecipientInfoフィールドのフィールドと同じ方法で使用されます。認証キーは、コンテンツ暗号化キーについて説明されているのと同じ方法でラップされます。
The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document.
送信エージェントは、このドキュメントのセクション2.2で指定されているように、静的-静的ECDHを使用したEnvelopedDataと同じアクションを使用します。
The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document.
受信エージェントは、このドキュメントのセクション2.3で指定されているように、静的-静的ECDHを使用したEnvelopedDataと同じアクションを使用します。
When using static-static ECDH with AuthEnvelopedData, the fields of AuthEnvelopedData are as in [RFC5083]. As static-static ECDH is a key-agreement algorithm, the RecipientInfo kari choice is used. When using static-static ECDH, the AuthEnvelopedData originatorInfo field MAY include the certificate(s) for the EC public key used in the formation of the pairwise key.
AuthEnvelopedDataで静的-静的ECDHを使用する場合、AuthEnvelopedDataのフィールドは[RFC5083]のようになります。静的静的ECDHは鍵合意アルゴリズムであるため、RecipientInfo kariの選択が使用されます。静的静的ECDHを使用する場合、AuthEnvelopedData originatorInfoフィールドには、ペアワイズキーの形成に使用されるEC公開キーの証明書を含めることができます（MAY）。
The AuthEnvelopedData KeyAgreeRecipientInfo fields are used in the same manner as the fields for the corresponding EnvelopedData KeyAgreeRecipientInfo fields of Section 2.1 of this document. The content-authenticated-encryption key is wrapped in the same manner as is described there for the content-encryption key.
AuthEnvelopedData KeyAgreeRecipientInfoフィールドは、このドキュメントのセクション2.1の対応するEnvelopedData KeyAgreeRecipientInfoフィールドのフィールドと同じ方法で使用されます。 content-authenticated-encryption鍵は、content-encryption鍵についてそこで説明されているのと同じ方法でラップされます。
The sending agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.2 of this document.
送信エージェントは、このドキュメントのセクション2.2で指定されているように、静的-静的ECDHを使用したEnvelopedDataと同じアクションを使用します。
The receiving agent uses the same actions as for EnvelopedData with static-static ECDH, as specified in Section 2.3 of this document.
受信エージェントは、このドキュメントのセクション2.3で指定されているように、静的-静的ECDHを使用したEnvelopedDataと同じアクションを使用します。
This document defines the use of static-static ECDH for EnvelopedData, AuthenticatedData, and AuthEnvelopedData. [RFC5753] defines ephemeral-static ECDH for EnvelopedData only.
このドキュメントでは、EnvelopedData、AuthenticatedData、AuthEnvelopedDataの静的静的ECDHの使用を定義します。 [RFC5753]は、EnvelopedDataに対してのみエフェメラルスタティックECDHを定義します。
With regard to EnvelopedData, this document and [RFC5753] greatly parallel each other. Both specify how to apply Elliptic Curve Diffie-Hellman and differ only on how the sender's public value is to be communicated to the recipient. In [RFC5753], the sender provides the public value explicitly by including an OriginatorPublicKey value in the originator field of KeyAgreeRecipientInfo. In this document, the sender includes a reference to a (certified) public value by including either an IssuerAndSerialNumber or SubjectKeyIdentifier value in the same field. Put another way, [RFC5753] provides an interpretation of a KeyAgreeRecipientInfo structure where: o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie-Hellman, and
EnvelopedDataに関しては、このドキュメントと[RFC5753]は互いに非常に類似しています。どちらも楕円曲線Diffie-Hellmanの適用方法を指定し、送信者の公開値を受信者に伝達する方法のみが異なります。 [RFC5753]では、送信者は、KeyAgreeRecipientInfoのoriginatorフィールドにOriginatorPublicKey値を含めることにより、パブリック値を明示的に提供します。このドキュメントでは、送信者は、同じフィールドにIssuerAndSerialNumberまたはSubjectKeyIdentifierのいずれかの値を含めることにより、（認証された）パブリック値への参照を含めます。別の言い方をすると、[RFC5753]は、KeyAgreeRecipientInfo構造の解釈を提供します。ここで、o keyEncryptionAlgorithm値は、楕円曲線Diffie-Hellmanを示し、
o the originator field contains an OriginatorPublicKey value.
o originatorフィールドにはOriginatorPublicKey値が含まれています。
This document, on the other hand, provides an interpretation of a KeyAgreeRecipientInfo structure where:
一方、このドキュメントは、KeyAgreeRecipientInfo構造の解釈を提供します。
o the keyEncryptionAlgorithm value indicates Elliptic Curve Diffie-Hellman, and
o keyEncryptionAlgorithm値は楕円曲線Diffie-Hellmanを示し、
o the originator field contains either an IssuerAndSerialNumber value or a SubjectKeyIdentifier value.
o originatorフィールドには、IssuerAndSerialNumber値またはSubjectKeyIdentifier値のいずれかが含まれています。
AuthenticatedData or AuthEnvelopedData messages, on the other hand, are not given any form of ECDH by [RFC5753]. This is appropriate: that document only defines ephemeral-static Diffie-Hellman, and this form of Diffie-Hellman does not (inherently) provide any form of data authentication or data-origin authentication. This document, on the other hand, requires that the sender use a certified public value. Thus, this form of key agreement provides implicit key authentication and, under some limited circumstances, data-origin authentication. (See Section 7.)
一方、AuthenticatedDataまたはAuthEnvelopedDataメッセージは、[RFC5753]によってECDHのいかなる形式も与えられません。これは適切です。そのドキュメントは、ephemeral-static Diffie-Hellmanのみを定義しており、この形式のDiffie-Hellmanは、（本質的に）いかなる形式のデータ認証またはデータオリジン認証も提供しません。一方、このドキュメントでは、送信者が公認の公開値を使用する必要があります。したがって、この形式の鍵合意は、暗黙的な鍵認証を提供し、一部の限られた状況下では、データ発信元認証を提供します。 （セクション7を参照。）
This document does not define any new ASN.1 structures or algorithm identifiers. It provides new ways to interpret structures from [RFC5652] and [RFC5753], and it allows previously defined algorithms to be used under these new interpretations. Specifically:
このドキュメントでは、新しいASN.1構造やアルゴリズム識別子は定義していません。 [RFC5652]と[RFC5753]の構造を解釈する新しい方法を提供し、以前に定義されたアルゴリズムをこれらの新しい解釈の下で使用できるようにします。具体的には：
o The ECDH key-agreement algorithm identifiers from [RFC5753] define only how Diffie-Hellman values are processed, and not where these values are created. Therefore, they can be used for static-static ECDH with no changes.
o [RFC5753]のECDH鍵合意アルゴリズム識別子は、Diffie-Hellman値の処理方法のみを定義し、これらの値が作成される場所は定義しません。したがって、変更なしで静的-静的ECDHに使用できます。
o The key-wrap, MAC, and digest algorithms referenced in [RFC5753] describe how the secret key is to be used but not created. Therefore, they can be used with keys from static-static ECDH without modification.
o [RFC5753]で参照されているキーラップ、MAC、およびダイジェストアルゴリズムは、秘密鍵をどのように使用するが作成しないかを説明しています。したがって、変更せずに静的-静的ECDHのキーで使用できます。
It is RECOMMENDED that implementations of this specification support AuthenticatedData and EnvelopedData. Support for AuthEnvelopedData is OPTIONAL.
この仕様の実装がAuthenticatedDataおよびEnvelopedDataをサポートすることをお勧めします。 AuthEnvelopedDataのサポートはオプションです。
Implementations that support this specification MUST support standard Elliptic Curve Diffie-Hellman, and these implementations MAY also support cofactor Elliptic Curve Diffie-Hellman.
この仕様をサポートする実装は、標準のElliptic Curve Diffie-Hellmanをサポートする必要があり、これらの実装は、補因子Elliptic Curve Diffie-Hellmanもサポートする場合があります。
In order to encourage interoperability, implementations SHOULD use the elliptic curve domain parameters specified by [RFC5480].
相互運用性を促進するために、実装は[RFC5480]で指定された楕円曲線ドメインパラメータを使用する必要があります（SHOULD）。
Implementations that support standard static-static Elliptic Curve Diffie-Hellman:
標準の静的-静的楕円曲線Diffie-Hellmanをサポートする実装：
o MUST support the dhSinglePass-stdDH-sha256kdf-scheme key-agreement algorithm;
o dhSinglePass-stdDH-sha256kdf-scheme鍵一致アルゴリズムをサポートする必要があります。
o MAY support the dhSinglePass-stdDH-sha224kdf-scheme, dhSinglePass-stdDH-sha384kdf-scheme, and dhSinglePass-stdDH-sha512kdf-scheme key-agreement algorithms; and
o dhSinglePass-stdDH-sha224kdf-scheme、dhSinglePass-stdDH-sha384kdf-scheme、およびdhSinglePass-stdDH-sha512kdf-scheme鍵合意アルゴリズムをサポートする場合があります。そして
o SHOULD NOT support the dhSinglePass-stdDH-sha1kdf-scheme algorithm.
o dhSinglePass-stdDH-sha1kdf-schemeアルゴリズムをサポートしないでください。
Other algorithms MAY also be supported.
他のアルゴリズムもサポートされるかもしれません。
Implementations that support cofactor static-static Elliptic Curve Diffie-Hellman:
補因子の静的-静的楕円曲線Diffie-Hellmanをサポートする実装：
o MUST support the dhSinglePass-cofactorDH-sha256kdf-scheme key-agreement algorithm;
o dhSinglePass-cofactorDH-sha256kdf-scheme鍵一致アルゴリズムをサポートする必要があります。
o MAY support the dhSinglePass-cofactorDH-sha224kdf-scheme, dhSinglePass-cofactorDH-sha384kdf-scheme, and dhSinglePass-cofactorDH-sha512kdf-scheme key-agreement algorithms; and
o dhSinglePass-cofactorDH-sha224kdf-scheme、dhSinglePass-cofactorDH-sha384kdf-scheme、およびdhSinglePass-cofactorDH-sha512kdf-scheme key-agreementアルゴリズムをサポートする場合があります。そして
o SHOULD NOT support the dhSinglePass-cofactorDH-sha1kdf-scheme algorithm.
o dhSinglePass-cofactorDH-sha1kdf-schemeアルゴリズムをサポートしないでください。
In addition, all implementations:
さらに、すべての実装：
o MUST support the id-aes128-wrap key-wrap algorithm and the id-aes128-cbc content-encryption algorithm;
o id-aes128-wrap key-wrapアルゴリズムとid-aes128-cbc content-encryptionアルゴリズムをサポートする必要があります。
o MAY support:
o サポートするかもしれません：
* the id-aes192-wrap and id-aes256-wrap key-wrap algorithms;
* id-aes192-wrapおよびid-aes256-wrapキーラップアルゴリズム。
* the id-aes128-CCM, id-aes192-CCM, id-aes256-CCM, id-aes128-GCM, id-aes192-GCM, and id-aes256-GCM authenticated-encryption algorithms; and
* id-aes128-CCM、id-aes192-CCM、id-aes256-CCM、id-aes128-GCM、id-aes192-GCM、およびid-aes256-GCM認証済み暗号化アルゴリズム。そして
* the id-aes192-cbc and id-aes256-cbc content-encryption algorithms.
* id-aes192-cbcおよびid-aes256-cbcコンテンツ暗号化アルゴリズム。
o SHOULD NOT support the id-alg-CMS3DESwrap key-wrap algorithm or the des-ede3-cbc content-encryption algorithms.
o id-alg-CMS3DESwrapキーラップアルゴリズムまたはdes-ede3-cbcコンテンツ暗号化アルゴリズムをサポートするべきではありません（SHOULD NOT）。
(All algorithms above are defined in [RFC3370], [RFC3565], [RFC5084], and [RFC5753].) Unless otherwise noted above, other algorithms MAY also be supported.
（上記のすべてのアルゴリズムは、[RFC3370]、[RFC3565]、[RFC5084]、および[RFC5753]で定義されています。）上記で特に明記されていない限り、他のアルゴリズムもサポートされる場合があります。
All security considerations in Section 9 of [RFC5753] apply.
[RFC5753]のセクション9のセキュリティに関するすべての考慮事項が適用されます。
Extreme care must be used when using static-static Diffie-Hellman (either standard or cofactor) without the use of some per-message value in the ukm. As described in [RFC5753], the ukm value (if present) will be embedded in an ECC-CMS-SharedInfo structure, and the DER encoding of this structure will be used as the 'SharedInfo' input to the key-derivation function of [X963]. The purpose of this input is to add a message-unique value to the key-distribution function so that two different sessions of static-static ECDH between a given pair of agents result in independent keys. If the ukm value is not used or is re-used, on the other hand, then the ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not vary from message to message. In this case, the two agents will re-use the same keying material across multiple messages. This is considered to be bad cryptographic practice and may open the sender to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack [MenezesUstaoglu] or other, yet-undiscovered attacks).
ukmでメッセージごとの値を使用せずにstatic-static Diffie-Hellman（標準または補因子）を使用する場合は、細心の注意を払う必要があります。 [RFC5753]で説明されているように、ukm値（存在する場合）はECC-CMS-SharedInfo構造に埋め込まれ、この構造のDERエンコードは、[の鍵導出関数への 'SharedInfo'入力として使用されます。 X963]。この入力の目的は、特定のエージェントのペア間で静的-静的ECDHの2つの異なるセッションが独立したキーになるように、メッセージ固有の値をキー配布機能に追加することです。一方、ukm値が使用されていないか、再使用されている場合、ECC-CMS-SharedInfo構造（および「SharedInfo」入力）はメッセージごとに変化しない可能性があります。この場合、2つのエージェントは複数のメッセージにわたって同じキー情報を再利用します。これは悪い暗号慣行と見なされ、送信者をDiffie-Hellmanへの攻撃（たとえば、「小さなサブグループ」攻撃[MenezesUstaoglu]またはその他の未発見の攻撃）にさらす可能性があります。
It is for these reasons that Section 2.1 states that message senders SHOULD include the ukm and SHOULD ensure that the value of ukm is unique to the message being sent. One way to ensure the uniqueness of the ukm is for the message sender to choose a 'sufficiently long' random string for each message (where, as a rule of thumb, a 'sufficiently long' string is one at least as long as the keys used by the key-wrap algorithm identified in the keyEncryptionAlgorithm field of the KeyAgreeRecipientInfo structure). However, other methods (such as a counter) are possible. Also, applications that cannot tolerate the inclusion of per-message information in the ukm (due to bandwidth requirements, for example) SHOULD NOT use static-static ECDH for a recipient without ascertaining that the recipient knows the private value associated with their certified Diffie-Hellman value.
これらの理由により、セクション2.1では、メッセージ送信者はukmを含める必要があり（SHOULD）、ukmの値は送信されるメッセージに固有であることを保証する必要がある（SHOULD）。 ukmの一意性を保証する1つの方法は、メッセージ送信者が各メッセージに対して「十分に長い」ランダムな文字列を選択することです（経験則として、「十分に長い」文字列は少なくともキーと同じ長さです） KeyAgreeRecipientInfo構造のkeyEncryptionAlgorithmフィールドで識別されるキーラップアルゴリズムで使用されます。ただし、他の方法（カウンターなど）も可能です。また、（帯域幅の要件などにより）ukmにメッセージごとの情報を含めることを許容できないアプリケーションは、受信者が認定済みDiffie-ヘルマン値。
Static-static Diffie-Hellman, when used as described in this document, does not necessarily provide data-origin authentication. Consider, for example, the following sequence of events: o Alice sends an AuthEnvelopedData message to both Bob and Mallory. Furthermore, Alice uses a static-static DH method to transport the content-authenticated-encryption key to Bob, and some arbitrary method to transport the same key to Mallory.
Static-static Diffie-Hellmanは、このドキュメントで説明されているように使用された場合、必ずしもデータオリジン認証を提供するわけではありません。たとえば、次の一連のイベントを考えてみます。oアリスがAuthEnvelopedDataメッセージをボブとマロリーの両方に送信します。さらに、アリスは静的静的DHメソッドを使用してコンテンツ認証済み暗号化キーをボブに転送し、任意のメソッドを使用して同じキーをマロリーに転送します。
o Mallory intercepts the message and prevents Bob from receiving it.
o マロリーはメッセージを傍受し、ボブがメッセージを受信できないようにします。
o Mallory recovers the content-authenticated-encryption key from the message received from Alice. Mallory then creates new plaintext of her choice, and encrypts it using the same authenticated-encryption algorithm and the same content-authenticated-encryption key used by Alice.
o マロリーは、アリスから受け取ったメッセージからコンテンツ認証された暗号化キーを回復します。次に、マロリーは選択した新しい平文を作成し、アリスが使用したのと同じ認証済み暗号化アルゴリズムと同じコンテンツ認証済み暗号化鍵を使用して暗号化します。
o Mallory then replaces the EncryptedContentInfo and MessageAuthenticationCode fields of Alice's message with the values Mallory just generated. She may additionally remove her RecipientInfo value from Alice's message.
o 次に、Malloryは、AliceのメッセージのEncryptedContentInfoおよびMessageAuthenticationCodeフィールドを、生成されたばかりのMalloryの値に置き換えます。さらに、アリスのメッセージから自分のRecipientInfo値を削除することもできます。
o Mallory sends the modified message to Bob.
o マロリーは変更されたメッセージをボブに送信します。
o Bob receives the message, validates the static-static DH values, and decrypts/authenticates the message.
o ボブはメッセージを受信し、静的-静的DH値を検証し、メッセージを復号化/認証します。
At this point, Bob has received and validated a message that appears to have been sent by Alice, but whose content was chosen by Mallory. Mallory may not even be an apparent receiver of the modified message. Thus, this use of static-static Diffie-Hellman does not necessarily provide data-origin authentication. (We note that this example does not also contradict either confidentiality or data authentication: Alice's message was not received by anyone not intended by Alice, and Mallory's message was not modified before reaching Bob.)
この時点で、ボブはアリスから送信されたように見えますが、その内容がマロリーによって選択されたメッセージを受信して検証しました。マロリーは変更されたメッセージの明らかな受信者でさえないかもしれません。したがって、この静的静的Diffie-Hellmanの使用は、必ずしもデータ起源の認証を提供するわけではありません。 （この例は、機密性またはデータ認証にも矛盾しないことに注意してください。アリスのメッセージは、アリスが意図していない人には受信されず、マロリーのメッセージはボブに到達する前に変更されませんでした。）
More generally, the data origin may not be authenticated unless:
より一般的には、次の場合を除いて、データの発信元は認証されません。
o it is a priori guaranteed that the message in question was sent to exactly one recipient, or
o 問題のメッセージが正確に1人の受信者に送信されたことが事前に保証されている、または
o data-origin authentication is provided by some other mechanism (such as digital signatures).
o data-origin authenticationは、他の何らかのメカニズム（デジタル署名など）によって提供されます。
However, we also note that this lack of authentication is not a product of static-static ECDH per se, but is inherent in the way key-agreement schemes are used in the AuthenticatedData and AuthEnvelopedData structures of the CMS.
ただし、この認証の欠如は、静的-静的ECDH自体の結果ではなく、CMSのAuthenticatedDataおよびAuthEnvelopedData構造で鍵合意スキームが使用される方法に固有のものであることにも注意します。
When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption by the sender's infrastructure would not be possible (though it would remain possible for the infrastructure of any recipient).
このドキュメントで説明されているように、2つのパーティが静的-静的ECDHを使用して通信していて、どちらかのパーティの非対称キーが中央で生成されている場合、そのパーティの中央インフラストラクチャが通信を復号化する可能性があります（アプリケーション層ネットワークの監視やフィルタリングなど） ）。対照的に、短命の静的ECDHが代わりに使用された場合、送信者のインフラストラクチャによるこのような復号化は不可能になります（ただし、受信者のインフラストラクチャでは引き続き可能です）。
This work is sponsored by the United States Air Force under Air Force Contract FA8721-05-C-0002. Opinions, interpretations, conclusions and recommendations are those of the authors and are not necessarily endorsed by the United States Government.
この作品は、空軍契約FA8721-05-C-0002に基づいて米国空軍が後援しています。意見、解釈、結論、および推奨事項は著者の意見であり、必ずしも米国政府によって承認されているわけではありません。
The authors would like to thank Jim Schaad, Russ Housley, Sean Turner, Brian Weis, Rene Struik, Brian Carpenter, David McGrew, and Stephen Farrell for their helpful comments and suggestions. We would also like to thank Jim Schaad for describing to us the attack described in Section 7.
著者は、有益なコメントと提案をしてくれたJim Schaad、Russ Housley、Sean Turner、Brian Weis、Rene Struik、Brian Carpenter、David McGrew、Stephen Farrellに感謝します。セクション7で説明した攻撃について説明してくれたJim Schaadにも感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[RFC3370] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、2002年8月。
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[RFC3565] Schaad、J。、「暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[RFC5083] Housley, R., "Cryptographic Message Syntax (CMS) Authenticated-Enveloped-Data Content Type", RFC 5083, November 2007.
[RFC5083] Housley、R。、「Cryptographic Message Syntax（CMS）Authenticated-Enveloped-Data Content Type」、RFC 5083、2007年11月。
[RFC5084] Housley, R., "Using AES-CCM and AES-GCM Authenticated Encryption in the Cryptographic Message Syntax (CMS)", RFC 5084, November 2007.
[RFC5084] Housley、R。、「Cryptographic Message Syntax（CMS）でのAES-CCMおよびAES-GCM Authenticated Encryptionの使用」、RFC 5084、2007年11月。
[RFC5480] Turner, S., Brown, D., Yiu, K., Housley, R., and T. Polk, "Elliptic Curve Cryptography Subject Public Key Information", RFC 5480, March 2009.
[RFC5480]ターナー、S。、ブラウン、D。、ユウ、K。、ハウズリー、R。、およびT.ポーク、「楕円曲線暗号サブジェクト公開鍵情報」、RFC 5480、2009年3月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC5753] Turner, S. and D. Brown, "Use of Elliptic Curve Cryptography (ECC) Algorithms in Cryptographic Message Syntax (CMS)", RFC 5753, January 2010.
[RFC5753]ターナーS.およびD.ブラウン、「暗号化メッセージ構文（CMS）での楕円曲線暗号化（ECC）アルゴリズムの使用」、RFC 5753、2010年1月。
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic Curve Cryptography Algorithms", RFC 6090, February 2011.
[RFC6090] McGrew、D.、Igoe、K。、およびM. Salter、「Fundamental Elliptic Curve Cryptography Algorithms」、RFC 6090、2011年2月。
[SP800-56A] Barker, E., Johnson, D., and M. Smid, "Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised)", NIST Special Publication (SP) 800-56A, March 2007.
[SP800-56A] Barker、E.、Johnson、D。、およびM. Smid、「離散対数暗号化を使用したペアワイズキー確立方式の推奨（改訂）」、NIST特別刊行物（SP）800-56A、2007年3月。
[X963] "Public Key Cryptography for the Financial Services Industry, Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, 2001.
[X963]「金融サービス業界の公開鍵暗号化、楕円曲線暗号化を使用した鍵合意および鍵転送」、ANSI X9.63、2001。
[MenezesUstaoglu] Menezes, A. and B. Ustaoglu, "On Reusing Ephemeral Keys in Diffie-Hellman Key Agreement Protocols", International Journal of Applied Cryptography, Vol. 2, No. 2, pp. 154- 158, 2010.
[MenezesUstaoglu] Menezes、A。およびB. Ustaoglu、「Diffie-Hellman鍵合意プロトコルでの短命鍵の再利用について」、International Journal of Applied Cryptography、Vol。 2、No。2、pp。154- 158、2010。
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[RFC2631] Rescorla、E。、「Diffie-Hellman Key Agreement Method」、RFC 2631、1999年6月。
[SEC1] Standards for Efficient Cryptography Group (SECG), "SEC 1: Elliptic Curve Cryptography", Version 2.0, May 2009.
[SEC1] Standards for Efficient Cryptography Group（SECG）、「SEC 1：Elliptic Curve Cryptography」、バージョン2.0、2009年5月。
[X.680] ITU-T, "Information Technology - Abstract Syntax Notation One: Specification of Basic Notation", Recommendation X.680, ISO/IEC 8824-1:2002, 2002.
[X.680] ITU-T、「Information Technology-Abstract Syntax Notation One：Specification of Basic Notation」、Recommendation X.680、ISO / IEC 8824-1：2002、2002。
[X.681] ITU-T, "Information Technology - Abstract Syntax Notation One: Information Object Specification", Recommendation X.681, ISO/IEC 8824-2:2002, 2002.
[X.681] ITU-T、「Information Technology-Abstract Syntax Notation One：Information Object Specification」、Recommendation X.681、ISO / IEC 8824-2：2002、2002。
[X.682] ITU-T, "Information Technology - Abstract Syntax Notation One: Constraint Specification", Recommendation X.682, ISO/ IEC 8824-3:2002, 2002.
[X.682] ITU-T、「Information Technology-Abstract Syntax Notation One：Constraint Specification」、Recommendation X.682、ISO / IEC 8824-3：2002、2002。
[X.683] ITU-T, "Information Technology - Abstract Syntax Notation One: Parameterization of ASN.1 Specifications", Recommendation X.683, ISO/IEC 8824-4:2002, 2002.
[X.683] ITU-T、「Information Technology-Abstract Syntax Notation One：Parameterization of ASN.1 Specifications」、Recommendation X.683、ISO / IEC 8824-4：2002、2002。
Authors' Addresses
著者のアドレス
Jonathan C. Herzog MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA
Jonathan C. Herzog MITリンカーン研究所244 Wood St. Lexington、MA 02144 USA
EMail: jherzog@ll.mit.edu
Roger Khazan MIT Lincoln Laboratory 244 Wood St. Lexington, MA 02144 USA
ロジャーカザンMITリンカーンラボラトリー244 Wood St. Lexington、MA 02144 USA
EMail: rkh@ll.mit.edu