RFC 8037 - CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc8037
タイトル : RFC 8037 - CFRG Elliptic Curve Diffie-Hellman（ECDH）とJSON Object Signing and Encryption（JOSE）の署名
翻訳編集 : 自動生成

[要約] RFC 8037は、JOSEでのECDHと署名のためのCFRG楕円曲線Diffie-Hellman（ECDH）の仕様です。このRFCの目的は、JOSEフレームワーク内での安全な鍵交換と署名の実装を提供することです。

Internet Engineering Task Force (IETF)                      I. Liusvaara
Request for Comments: 8037                                   Independent
Category: Standards Track                                   January 2017
ISSN: 2070-1721

CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)

CFRG Elliptic Curve Diffie-Hellman（ECDH）とJSON Object Signing and Encryption（JOSE）の署名

Abstract

概要

This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).

このドキュメントでは、Diffie-Hellmanアルゴリズム「X25519」と「X448」、およびIRTF CFRG楕円曲線の署名アルゴリズム「Ed25519」と「Ed448」をJSONオブジェクトの署名と暗号化（JOSE）で使用する方法を定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これは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). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8037.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8037で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.

この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（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.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Key Type "OKP"  . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Signing . . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.2.  Verification  . . . . . . . . . . . . . . . . . . . .   4
     3.2.  ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . .   4
       3.2.1.  Performing the ECDH Operation . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     6.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     6.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   9
     A.1.  Ed25519 Private Key . . . . . . . . . . . . . . . . . . .   9
     A.2.  Ed25519 Public Key  . . . . . . . . . . . . . . . . . . .   9
     A.3.  JWK Thumbprint Canonicalization . . . . . . . . . . . . .   9
     A.4.  Ed25519 Signing . . . . . . . . . . . . . . . . . . . . .  10
     A.5.  Ed25519 Validation  . . . . . . . . . . . . . . . . . . .  11
     A.6.  ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . .  11
     A.7.  ECDH-ES with X448 . . . . . . . . . . . . . . . . . . . .  12
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1. Introduction

1. はじめに

   The Internet Research Task Force (IRTF) Crypto Forum Research Group
   (CFRG) selected new Diffie-Hellman algorithms ("X25519" and "X448";
   [RFC7748]) and signature algorithms ("Ed25519" and "Ed448";
   [RFC8032]) for asymmetric key cryptography.  This document defines
   how to use those algorithms in JOSE in an interoperable manner.

This document defines the conventions to use in the context of [RFC7515], [RFC7516], and [RFC7517].

このドキュメントは、[RFC7515]、[RFC7516]、および[RFC7517]のコンテキストで使用する規則を定義します。

While the CFRG also defined two pairs of isogenous elliptic curves that underlie these algorithms, these curves are not directly exposed, as the algorithms laid on top are sufficient for the purposes of JOSE and are much easier to use.

CFRGはこれらのアルゴリズムの基礎となる2組の同質楕円曲線も定義しましたが、これらの曲線は直接公開されていません。これは、上に配置されたアルゴリズムがJOSEの目的に十分であり、はるかに使いやすいためです。

All inputs to and outputs from the Elliptic Curve Diffie-Hellman (ECDH) and signature functions are defined to be octet strings, with the exception of outputs of verification functions, which are booleans.

ブール値である検証関数の出力を除いて、楕円曲線ディフィーヘルマン（ECDH）へのすべての入力と出力、および署名関数はオクテット文字列として定義されます。

1.1. 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 [RFC2119].

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。

"JWS Signing Input" and "JWS Signature" are defined by [RFC7515].

「JWS署名入力」と「JWS署名」は[RFC7515]で定義されています。

"Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" is defined by Section 4.6 of [RFC7518].

「楕円曲線Diffie-Hellman Ephemeral Staticとの主要な合意」は、[RFC7518]のセクション4.6で定義されています。

The JOSE key format ("JSON Web Key (JWK)") is defined by [RFC7517] and thumbprints for it ("JSON Web Key (JWK) Thumbprint") in [RFC7638].

JOSEキー形式（「JSON Webキー（JWK）」）は、[RFC7517]および[RFC7638]のそのサムプリント（「JSON Webキー（JWK）サムプリント」）によって定義されています。

2. Key Type "OKP"

2. キータイプ「OKP」

A new key type (kty) value "OKP" (Octet Key Pair) is defined for public key algorithms that use octet strings as private and public keys. It has the following parameters:

新しいキータイプ（kty）値「OKP」（オクテットキーペア）は、オクテット文字列をプライベートキーおよびパブリックキーとして使用する公開キーアルゴリズム用に定義されています。次のパラメーターがあります。

o The parameter "kty" MUST be "OKP".

o パラメータ「kty」は「OKP」である必要があります。

o The parameter "crv" MUST be present and contain the subtype of the key (from the "JSON Web Elliptic Curve" registry).

o パラメータ「crv」が存在し、（「JSON Web Elliptic Curve」レジストリからの）キーのサブタイプを含んでいる必要があります。

o The parameter "x" MUST be present and contain the public key encoded using the base64url [RFC4648] encoding.

o パラメータ「x」が存在し、base64url [RFC4648]エンコーディングを使用してエンコードされた公開鍵を含んでいる必要があります。

o The parameter "d" MUST be present for private keys and contain the private key encoded using the base64url encoding. This parameter MUST NOT be present for public keys.

o パラメータ「d」は秘密鍵に存在しなければならず、base64urlエンコーディングを使用してエンコードされた秘密鍵を含んでいる必要があります。このパラメーターは公開鍵に存在してはなりません（MUST NOT）。

Note: Do not assume that there is an underlying elliptic curve, despite the existence of the "crv" and "x" parameters. (For instance, this key type could be extended to represent Diffie-Hellman (DH) algorithms based on hyperelliptic surfaces.)

注：「crv」パラメータと「x」パラメータが存在するにもかかわらず、基礎となる楕円曲線があると仮定しないでください。（たとえば、このキータイプは、超楕円曲面に基づくDiffie-Hellman（DH）アルゴリズムを表すように拡張できます。）

When calculating JWK Thumbprints [RFC7638], the three public key fields are included in the hash input in lexicographic order: "crv", "kty", and "x".

JWK Thumbprints [RFC7638]を計算するとき、3つの公開鍵フィールドが辞書入力順にハッシュ入力に含まれます：「crv」、「kty」、および「x」。

3. Algorithms

3. アルゴリズム

3.1. Signatures

3.1. 署名

For the purpose of using the Edwards-curve Digital Signature Algorithm (EdDSA) for signing data using "JSON Web Signature (JWS)" [RFC7515], algorithm "EdDSA" is defined here, to be applied as the value of the "alg" parameter.

"JSON Web Signature（JWS）" [RFC7515]を使用してデータに署名するためにEdwards-curve Digital Signature Algorithm（EdDSA）を使用する目的で、アルゴリズム "EdDSA"がここで定義され、 "alg"の値として適用されますパラメータ。

The following key subtypes are defined here for use with EdDSA:

EdDSAで使用するために、次の主要なサブタイプがここで定義されています。

"crv" EdDSA Variant Ed25519 Ed25519 Ed448 Ed448

"ワーム" EddsaオプションEd25519 Ed25519 Ed448 Ed448

The key type used with these keys is "OKP" and the algorithm used for signing is "EdDSA". These subtypes MUST NOT be used for Elliptic Curve Diffie-Hellman Ephemeral Static (ECDH-ES).

これらの鍵で使用される鍵タイプは「OKP」であり、署名に使用されるアルゴリズムは「EdDSA」です。これらのサブタイプは、楕円曲線Diffie-Hellman Ephemeral Static（ECDH-ES）には使用しないでください。

The EdDSA variant used is determined by the subtype of the key (Ed25519 for "Ed25519" and Ed448 for "Ed448").

使用されるEdDSAバリアントは、キーのサブタイプによって決まります（「Ed25519」の場合はEd25519、「Ed448」の場合はEd448）。

3.1.1. Signing

3.1.1. 署名

Signing for these is performed by applying the signing algorithm defined in [RFC8032] to the private key (as private key), public key (as public key), and the JWS Signing Input (as message). The resulting signature is the JWS Signature. All inputs and outputs are octet strings.

これらの署名は、[RFC8032]で定義されている署名アルゴリズムを秘密鍵（秘密鍵として）、公開鍵（公開鍵として）、およびJWS署名入力（メッセージとして）に適用することによって実行されます。結果の署名はJWS署名です。すべての入力と出力はオクテット文字列です。

3.1.2. Verification

3.1.2. 検証

Verification is performed by applying the verification algorithm defined in [RFC8032] to the public key (as public key), the JWS Signing Input (as message), and the JWS Signature (as signature). All inputs are octet strings. If the algorithm accepts, the signature is valid; otherwise, the signature is invalid.

検証は、[RFC8032]で定義されている検証アルゴリズムを公開鍵（公開鍵として）、JWS署名入力（メッセージとして）、およびJWS署名（署名として）に適用することによって実行されます。すべての入力はオクテット文字列です。アルゴリズムが受け入れる場合、署名は有効です。それ以外の場合、署名は無効です。

3.2. ECDH-ES

The following key subtypes are defined here for purpose of "Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" (ECDH-ES):

ここでは、「楕円曲線Diffie-Hellman Ephemeral Staticとの鍵合意」（ECDH-ES）を目的として、次の主要なサブタイプが定義されています。

"crv" ECDH Function Applied X25519 X25519 X448 X448

「crv」ECDH機能の適用X25519 X25519 X448 X448

The key type used with these keys is "OKP". These subtypes MUST NOT be used for signing.

これらのキーで使用されるキータイプは「OKP」です。これらのサブタイプは、署名に使用してはなりません（MUST NOT）。

Section 4.6 of [RFC7518] defines the ECDH-ES algorithms "ECDH-ES+A128KW", "ECDH-ES+A192KW", "ECDH-ES+A256KW", and "ECDH-ES".

[RFC7518]のセクション4.6は、ECDH-ESアルゴリズム「ECDH-ES + A128KW」、「ECDH-ES + A192KW」、「ECDH-ES + A256KW」、および「ECDH-ES」を定義しています。

3.2.1. Performing the ECDH Operation

3.2.1. ECDH操作の実行

The "x" parameter of the "epk" field is set as follows:

「epk」フィールドの「x」パラメーターは次のように設定されます。

Apply the appropriate ECDH function to the ephemeral private key (as scalar input) and the standard base point (as u-coordinate input). The base64url encoding of the output is the value for the "x" parameter of the "epk" field. All inputs and outputs are octet strings.

適切なECDH関数をエフェメラル秘密キー（スカラー入力として）および標準ベースポイント（u座標入力として）に適用します。出力のbase64urlエンコーディングは、「epk」フィールドの「x」パラメーターの値です。すべての入力と出力はオクテット文字列です。

The Z value (raw key agreement output) for key agreement (to be used in subsequent Key Derivation Function (KDF) as per Section 4.6.2 of [RFC7518]) is determined as follows:

鍵合意（[RFC7518]のセクション4.6.2に従って後続の鍵導出関数（KDF）で使用される）のZ値（生の鍵合意出力）は、次のように決定されます。

Apply the appropriate ECDH function to the ephemeral private key (as scalar input) and receiver public key (as u-coordinate input). The output is the Z value. All inputs and outputs are octet strings.

一時的な秘密鍵（スカラー入力として）と受信者の公開鍵（u座標入力として）に適切なECDH関数を適用します。出力はZ値です。すべての入力と出力はオクテット文字列です。

4. Security Considerations

4. セキュリティに関する考慮事項

Security considerations from [RFC7748] and [RFC8032] apply here.

[RFC7748]および[RFC8032]のセキュリティに関する考慮事項がここに適用されます。

Do not separate key material from information about what key subtype it is for. When using keys, check that the algorithm is compatible with the key subtype for the key. To do otherwise opens the system up to attacks via mixing up algorithms. It is particularly dangerous to mix up signature and Message Authentication Code (MAC) algorithms.

キーマテリアルを、それがどのキーサブタイプであるかに関する情報から分離しないでください。鍵を使用する場合は、アルゴリズムが鍵の鍵サブタイプと互換性があることを確認してください。それ以外の場合は、アルゴリズムを混合することにより、システムを攻撃から解放します。署名アルゴリズムとメッセージ認証コード（MAC）アルゴリズムを混同することは特に危険です。

Although for Ed25519 and Ed448, the signature binds the key used for signing, do not assume this, as there are many signature algorithms that fail to make such a binding. If key-binding is desired, include the key used for signing either inside the JWS protected header or the data to sign.

Ed25519とEd448の場合、署名は署名に使用されるキーをバインドしますが、そのようなバインドに失敗する多くの署名アルゴリズムがあるため、これを想定しないでください。キーバインディングが必要な場合は、署名に使用するキーをJWS保護ヘッダー内または署名するデータのいずれかに含めます。

If key generation or batch signature verification is performed, a well-seeded cryptographic random number generator is REQUIRED. Signing and non-batch signature verification are deterministic operations and do not need random numbers of any kind.

鍵生成またはバッチ署名検証を実行する場合は、適切にシードされた暗号化乱数ジェネレーターが必要です。署名と非バッチ署名の検証は確定的な操作であり、いかなる種類の乱数も必要としません。

The JSON Web Algorithm (JWA) ECDH-ES KDF construction does not mix keys into the final shared secret. In key exchange, such mixing could be a bad mistake; whereas here either the receiver public key has to be chosen maliciously or the sender has to be malicious in order to cause problems. In either case, all security evaporates.

JSON Web Algorithm（JWA）ECDH-ES KDFの構築では、最終的な共有シークレットにキーを混在させません。鍵交換では、そのような混合は悪い間違いである可能性があります。一方、ここでは、問題を引き起こすために、受信者の公開鍵が悪意を持って選択されるか、送信者が悪意がある必要があります。どちらの場合も、すべてのセキュリティが失われます。

The nominal security strengths of X25519 and X448 are ~126 and ~223 bits. Therefore, using 256-bit symmetric encryption (especially key wrapping and encryption) with X448 is RECOMMENDED.

X25519およびX448の公称セキュリティ強度は、約126ビットと約223ビットです。したがって、X448で256ビットの対称暗号化（特に鍵の折り返しと暗号化）を使用することをお勧めします。

5. IANA Considerations

5. IANAに関する考慮事項

The following has been added to the "JSON Web Key Types" registry:

「JSON Web Key Types」レジストリに以下が追加されました。

   o  "kty" Parameter Value: "OKP"
   o  Key Type Description: Octet string key pairs
   o  JOSE Implementation Requirements: Optional
   o  Change Controller: IESG
   o  Specification Document(s): Section 2 of RFC 8037

The following has been added to the "JSON Web Key Parameters" registry:

「JSON Web Key Parameters」レジストリに以下が追加されました。

o Parameter Name: "crv" o Parameter Description: The subtype of key pair o Parameter Information Class: Public o Used with "kty" Value(s): "OKP" o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8037

o パラメータ名：「crv」oパラメータの説明：鍵ペアのサブタイプoパラメータ情報クラス：公開o「kty」の値で使用：「OKP」o変更コントローラ：IESG o仕様書：セクション2 RFC 8037

o Parameter Name: "d" o Parameter Description: The private key o Parameter Information Class: Private o Used with "kty" Value(s): "OKP" o Change Controller: IESG o Specification Document(s): Section 2 of RFC 8037

o パラメータ名：「d」oパラメータの説明：秘密鍵oパラメータ情報クラス：Private o「kty」の値で使用：「OKP」oコントローラの変更：IESG o仕様書：RFC 8037のセクション2

   o  Parameter Name: "x"
   o  Parameter Description: The public key
   o  Parameter Information Class: Public
   o  Used with "kty" Value(s): "OKP"
   o  Change Controller: IESG
   o  Specification Document(s): Section 2 of RFC 8037
   The following has been added to the "JSON Web Signature and
   Encryption Algorithms" registry:

o Algorithm Name: "EdDSA" o Algorithm Description: EdDSA signature algorithms o Algorithm Usage Location(s): "alg" o JOSE Implementation Requirements: Optional o Change Controller: IESG

o アルゴリズム名： "EdDSA" oアルゴリズムの説明：EdDSA署名アルゴリズムoアルゴリズムの使用場所： "alg" o JOSE実装要件：オプションo変更コントローラー：IESG

o Specification Document(s): Section 3.1 of RFC 8037 o Algorithm Analysis Documents(s): [RFC8032]

o 仕様文書：RFC 8037のセクション3.1 oアルゴリズム分析文書：[RFC8032]

The following has been added to the "JSON Web Key Elliptic Curve" registry:

「JSON Web Key Elliptic Curve」レジストリに以下が追加されました。

o Curve Name: "Ed25519" o Curve Description: Ed25519 signature algorithm key pairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.1 of RFC 8037

o 曲線名：「Ed25519」o曲線の説明：Ed25519署名アルゴリズムキーペアo JOSE実装要件：オプションo変更コントローラ：IESG o仕様書：RFC 8037のセクション3.1

o Curve Name: "Ed448" o Curve Description: Ed448 signature algorithm key pairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.1 of RFC 8037

o 曲線名：「Ed448」o曲線の説明：Ed448署名アルゴリズムキーペアo JOSE実装要件：オプションo変更コントローラ：IESG o仕様書：RFC 8037のセクション3.1

o Curve name: "X25519" o Curve Description: X25519 function key pairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of RFC 8037 o Analysis Documents(s): [RFC7748]

o 曲線名：「X25519」o曲線の説明：X25519ファンクションキーペアo JOSE実装要件：オプションo変更コントローラー：IESG o仕様文書：RFC 8037のセクション3.2 o分析文書：[RFC7748]

o Curve Name: "X448" o Curve Description: X448 function key pairs o JOSE Implementation Requirements: Optional o Change Controller: IESG o Specification Document(s): Section 3.2 of RFC 8037 o Analysis Documents(s): [RFC7748]

o 曲線名：「X448」o曲線の説明：X448ファンクションキーペアo JOSE実装要件：オプションo変更管理者：IESG o仕様文書：RFC 8037のセクション3.2 o分析文書：[RFC7748]

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.

[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <http://www.rfc-editor.org/info/rfc7515>.

[RFC7515]ジョーンズ、M。、ブラッドリー、J。、およびN.崎村、「JSON Web Signature（JWS）」、RFC 7515、DOI 10.17487 / RFC7515、2015年5月、<http://www.rfc-editor.org / info / rfc7515>。

[RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/RFC7517, May 2015, <http://www.rfc-editor.org/info/rfc7517>.

[RFC7517]ジョーンズ、M。、「JSON Web Key（JWK）」、RFC 7517、DOI 10.17487 / RFC7517、2015年5月、<http://www.rfc-editor.org/info/rfc7517>。

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015, <http://www.rfc-editor.org/info/rfc7518>.

[RFC7518]ジョーンズ、M。、「JSON Web Algorithms（JWA）」、RFC 7518、DOI 10.17487 / RFC7518、2015年5月、<http://www.rfc-editor.org/info/rfc7518>。

[RFC7638] Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <http://www.rfc-editor.org/info/rfc7638>.

[RFC7638]ジョーンズ、M。およびN.崎村、「JSON Web Key（JWK）Thumbprint」、RFC 7638、DOI 10.17487 / RFC7638、2015年9月、<http://www.rfc-editor.org/info/rfc7638> 。

[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <http://www.rfc-editor.org/info/rfc7748>.

[RFC7748]ラングレー、A。、ハンブルク、M。、およびS.ターナー、「セキュリティのための楕円曲線」、RFC 7748、DOI 10.17487 / RFC7748、2016年1月、<http://www.rfc-editor.org/info / rfc7748>。

[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, DOI 10.17487/RFC8032, January 2017, <http://www.rfc-editor.org/info/rfc8032>.

[RFC8032] Josefsson、S。およびI. Liusvaara、「Edwards-Curve Digital Signature Algorithm（EdDSA）」、RFC 8032、DOI 10.17487 / RFC8032、2017年1月、<http://www.rfc-editor.org/info/ rfc8032>。

6.2. Informative References

6.2. 参考引用

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, <http://www.rfc-editor.org/info/rfc7516>.

[RFC7516]ジョーンズ、M。およびJ.ヒルデブランド、「JSON Web Encryption（JWE）」、RFC 7516、DOI 10.17487 / RFC7516、2015年5月、<http://www.rfc-editor.org/info/rfc7516>。

Appendix A. Examples

付録A.例

To the extent possible, these examples use material taken from test vectors of [RFC7748] and [RFC8032].

これらの例では、可能な限り、[RFC7748]と[RFC8032]のテストベクトルから取得した資料を使用しています。

A.1. Ed25519 Private Key

A.1. Ed25519秘密鍵

   {"kty":"OKP","crv":"Ed25519",
   "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A",
   "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}

The hexadecimal dump of private key is:

秘密鍵の16進ダンプは次のとおりです。

9d 61 b1 9d ef fd 5a 60 ba 84 4a f4 92 ec 2c c4 44 49 c5 69 7b 32 69 19 70 3b ac 03 1c ae 7f 60

And of the public key is:

そして公開鍵は：

d7 5a 98 01 82 b1 0a b7 d5 4b fe d3 c9 64 07 3a 0e e1 72 f3 da a6 23 25 af 02 1a 68 f7 07 51 1a

A.2. Ed25519 Public Key

A.2. Ed25519公開鍵

This is the public part of the previous private key (which just omits "d"):

これは以前の秘密鍵の公開部分です（ "d"を省略しているだけです）：

   {"kty":"OKP","crv":"Ed25519",
   "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}

A.3. JWK Thumbprint Canonicalization

A.3. JWKサムプリント正規化

The JWK Thumbprint canonicalization of the two examples above (with a linebreak inserted for formatting reasons) is:

上記の2つの例のJWK Thumbprint正規化（フォーマット上の理由で改行が挿入されています）は次のとおりです。

   {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI
   aaPcHURo"}

Which has the SHA-256 hash (in hexadecimal) of 90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89, which results in the base64url encoded JWK Thumbprint representation of "kPrK_qmxVWaYVA9wwBF6Iuo3vVzz7TxHCTwXBygrS4k".

これには、90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89のSHA-256ハッシュ（16進数）があり、base64urlでエンコードされたJWK Thumbprint表現で「kPrK_qmxVWaYVA9wwBF6Iuo3TVkwXWkWvwwwvwwvwwvwwvwwvwwvwwvwwvwwbwwvwwvwwvwwvww7wxwGv4ww7TxX

A.4. Ed25519 Signing

A.4. Ed25519署名

The JWS protected header is:

JWS保護ヘッダーは次のとおりです。

   {"alg":"EdDSA"}

This has the base64url encoding of:

これはbase64urlエンコーディングを持っています：

eyJhbGciOiJFZERTQSJ9

The payload is (text):

ペイロードは（テキスト）です。

Example of Ed25519 signing

Ed25519署名の例

This has the base64url encoding of:

これはbase64urlエンコーディングを持っています：

   RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc

The JWS signing input is (a concatenation of base64url encoding of the (protected) header, a dot, and base64url encoding of the payload) is:

JWS署名入力は（（保護された）ヘッダーのbase64urlエンコーディング、ドット、およびペイロードのbase64urlエンコーディングの連結）は次のとおりです。

   eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc

Applying the Ed25519 signing algorithm using the private key, public key, and the JWS signing input yields the signature (hex):

秘密鍵、公開鍵、およびJWS署名入力を使用してEd25519署名アルゴリズムを適用すると、署名（16進数）が生成されます。

86 0c 98 d2 29 7f 30 60 a3 3f 42 73 96 72 d6 1b 53 cf 3a de fe d3 d3 c6 72 f3 20 dc 02 1b 41 1e 9d 59 b8 62 8d c3 51 e2 48 b8 8b 29 46 8e 0e 41 85 5b 0f b7 d8 3b b1 5b e9 02 bf cc b8 cd 0a 02

Converting this to base64url yields:

これをbase64urlに変換すると、次のようになります。

hgyY0il_MGCjP0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt 9g7sVvpAr_MuM0KAg

So the compact serialization of the JWS is (a concatenation of signing input, a dot, and base64url encoding of the signature):

したがって、JWSのコンパクトなシリアル化は次のとおりです（署名の入力、ドット、および署名のbase64urlエンコーディングの連結）。

eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu M0KAg

えｙＪｈｂＧしおいＪＦぜＲＴＱＳＪ９。ＲＸっｈｂＸＢｓＺＳＢｖじＢＦＺぢ１んて５いＨんｐＺ２５ｐｂｍｃ。ｈｇっｙ０いｌ＿ＭＧＣｊＰ０Ｊ→んＬＷＧ１っぽｔ７ー０９ＰＧｃｖＭｇ３あいｂＱＲ６ｄＷｂひｊｃんＲ４き４いｙｌＧｊｇ５ＢｈＶｓＰｔ９ｇ７ｓっｖぱｒ＿むＭ０かｇ

A.5. Ed25519 Validation

A.5. Ed25519検証

The JWS from the example above is:

上記の例のJWSは次のとおりです。

eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu M0KAg

This has 2 dots in it, so it might be valid a JWS. Base64url decoding the protected header yields:

これには2つのドットがあるため、JWSとして有効である可能性があります。保護されたヘッダーをデコードするBase64urlは以下を生成します：

   {"alg":"EdDSA"}

So this is an EdDSA signature. Now the key has: "kty":"OKP" and "crv":"Ed25519", so the signature is Ed25519 signature.

つまり、これはEdDSAの署名です。これで、キーは "kty"： "OKP"および "crv"： "Ed25519"になるため、署名はEd25519署名になります。

The signing input is the part before the second dot:

署名入力は、2番目のドットの前の部分です。

   eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc

Applying the Ed25519 verification algorithm to the public key, JWS signing input, and the signature yields true. So the signature is valid. The message is the base64url decoding of the part between the dots:

Ed25519検証アルゴリズムを公開鍵、JWS署名入力、および署名に適用すると、trueが生成されます。したがって、署名は有効です。メッセージは、ドットの間の部分のbase64urlデコードです。

Example of Ed25519 Signing

Ed25519署名の例

A.6. ECDH-ES with X25519

A.6. X25519を搭載したECDH-ES

The public key to encrypt to is:

暗号化する公開鍵は次のとおりです。

   {"kty":"OKP","crv":"X25519","kid":"Bob",
   "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"}

The public key from the target key is (hex):

ターゲットキーからの公開キーは（16進数）です。

de 9e db 7d 7b 7d c1 b4 d3 5b 61 c2 ec e4 35 37 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f

de 9e db 7d 7b 7d c1 b4 d 5b 61 c2 ec e4 35 37 3f 83 43 c8 5b 78 67 4d ad fc 7e 14 6f 88 2b 4f

The ephemeral secret happens to be (hex):

一時的な秘密はたまたま（hex）です。

77 07 6d 0a 73 18 a5 7d 3c 16 c1 72 51 b2 66 45 df 4c 2f 87 eb c0 99 2a b1 77 fb a5 1d b9 2c 2a

So the ephemeral public key is X25519(ephkey, G) (hex):

したがって、一時的な公開鍵はX25519（ephkey、G）（hex）です。

85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6a This is represented as the ephemeral public key value:

85 20 f0 09 89 30 a7 54 74 8b 7d dc b4 3e f7 5a 0d bf 3a 0d 26 38 1a f4 eb a4 a9 8e aa 9b 4e 6aこれは一時的な公開鍵の値として表されます。

   {"kty":"OKP","crv":"X25519",
   "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}

So the protected header could be, for example:

したがって、保護されたヘッダーは、たとえば次のようになります。

   {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519",
   "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},
   "enc":"A128GCM","kid":"Bob"}

And the sender computes the DH Z value as X25519(ephkey, recv_pub) (hex):

そして、送信者はDH Z値をX25519（ephkey、recv_pub）（hex）として計算します。

4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42

ча5дяд5бачче2де1728езбфч80 350ф25е0ще21тячщд1ееззф0ябзц1е16 17 42

The receiver computes the DH Z value as X25519(seckey, ephkey_pub) (hex):

レシーバーは、DH Z値をX25519（seckey、ephkey_pub）（hex）として計算します。

4a 5d 9d 5b a4 ce 2d e1 72 8e 3b f4 80 35 0f 25 e0 7e 21 c9 47 d1 9e 33 76 f0 9b 3c 1e 16 17 42

ча5дяд5бачче2де1728езбфч80 350ф25е0ще21тячщд1ееззф0ябзц1е16 17 42

This is the same as the sender's value (both sides run this through the KDF before using it as a direct encryption key or AES128-KW key).

これは送信者の値と同じです（直接暗号化キーまたはAES128-KWキーとして使用する前に、両側でKDFを介して実行されます）。

A.7. ECDH-ES with X448

A.7. EC448-ESとX448

The public key to encrypt to (with a linebreak inserted for formatting reasons) is:

暗号化する公開鍵（フォーマット上の理由で改行が挿入されています）は次のとおりです。

   {"kty":"OKP","crv":"X448","kid":"Dave",
   "x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2
   uB73BxnvzNgk"}

The public key from the target key is (hex):

ターゲットキーからの公開キーは（16進数）です。

3e b7 a8 29 b0 cd 20 f5 bc fc 0b 59 9b 6f ec cf 6d a4 62 71 07 bd b0 d4 f3 45 b4 30 27 d8 b9 72 fc 3e 34 fb 42 32 a1 3c a7 06 dc b5 7a ec 3d ae 07 bd c1 c6 7b f3 36 09

The ephemeral secret happens to be (hex):

一時的な秘密はたまたま（hex）です。

9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 9a c2 d8 c0 a5 98 72 6b So the ephemeral public key is X448(ephkey, G) (hex):

9a 8f 49 25 d1 51 9f 57 75 cf 46 b0 4b 58 00 d4 ee 9e e8 ba e8 bc 55 65 d4 98 c2 8d d9 c9 ba f5 74 a9 41 97 44 89 73 91 00 63 82 a6 f1 27 ab 1d 9a c2 d8 c0 a5 98 72 6bしたがって、一時的な公開鍵はX448（ephkey、G）（hex）です。

9b 08 f7 cc 31 b7 e3 e6 7d 22 d5 ae a1 21 07 4a 27 3b d2 b8 3d e0 9c 63 fa a7 3d 2c 22 c5 d9 bb c8 36 64 72 41 d9 53 d4 0c 5b 12 da 88 12 0d 53 17 7f 80 e5 32 c4 1f a0

This is packed into the ephemeral public key value (a linebreak inserted for formatting purposes):

これは一時的な公開鍵の値にパックされます（フォーマットのために改行が挿入されます）。

   {"kty":"OKP","crv":"X448",
   "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1
   TF3-A5TLEH6A"}

So the protected header could be, for example (a linebreak inserted for formatting purposes):

したがって、保護されたヘッダーは、たとえば次のようになります（フォーマットのために改行が挿入されます）。

   {"alg":"ECDH-ES+A256KW","epk":{"kty":"OKP","crv":"X448",
   "x":"mwj3zDG34-Z9ItWuoSEHSic70rg94Jxj-qc9LCLF2bvINmRyQdlT1AxbEtqIEg1
   TF3-A5TLEH6A"},"enc":"A256GCM","kid":"Dave"}

And the sender computes the DH Z value as X448(ephkey,recv_pub) (hex):

そして、送信者はDH Z値をX448（ephkey、recv_pub）（hex）として計算します。

07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 44 9a 50 37 51 4a 87 9d

The receiver computes the DH Z value as X448(seckey, ephkey_pub) (hex):

レシーバーはDH Z値をX448（seckey、ephkey_pub）（hex）として計算します。

07 ff f4 18 1a c6 cc 95 ec 1c 16 a9 4a 0f 74 d1 2d a2 32 ce 40 a7 75 52 28 1d 28 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 36 52 1c 24 40 30 85 d5 9a 44 9a 50 37 51 4a 87 9d

This is the same as the sender's value (both sides run this through KDF before using it as the direct encryption key or AES256-KW key).

これは送信者の値と同じです（直接暗号化キーまたはAES256-KWキーとして使用する前に、両側でKDFを使用して実行されます）。

Acknowledgements

謝辞

Thanks to Michael B. Jones for his comments on an initial draft of this document and editorial help.

このドキュメントの最初の草案に対するコメントと編集の手助けをしてくれたMichael B. Jonesに感謝します。

Thanks to Matt Miller for some editorial help.

編集の手助けをしてくれたMatt Millerに感謝します。

Author's Address

著者のアドレス

Ilari Liusvaara Independent

Ilari Liusvaara独立

   Email: ilariliusvaara@welho.com