Internet Engineering Task Force (IETF) I. Liusvaara
Request for Comments: 8037 Independent
Category: Standards Track January 2017
ISSN: 2070-1721
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椭圆曲线Diffie-Hellman（ECDH）和JSON对象签名和加密（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).
本文档定义了如何在JSON对象签名和加密（JOSE）中使用Diffie-Hellman算法“X25519”和“X448”以及IRTF CFRG椭圆曲线中的签名算法“Ed25519”和“Ed448”。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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 . . . . . . . . . . . . . . . . . . . . . . . . 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
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.
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还定义了两对同构椭圆曲线作为这些算法的基础，但这些曲线不会直接暴露出来，因为上面的算法足以满足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.
椭圆曲线Diffie-Hellman（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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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].
[RFC7518]第4.6节定义了“椭圆曲线Diffie-Hellman瞬时静态密钥协议”。
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）指纹”）定义。
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椭圆曲线”注册表）。
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编码的私钥。公钥不能存在此参数。
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指纹[RFC7638]时，三个公钥字段按字典顺序包含在哈希输入中：“crv”、“kty”和“x”。
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.
为了使用Edwards曲线数字签名算法（EdDSA）对使用“JSON Web签名（JWS）”[RFC7515]的数据进行签名，这里定义了算法“EdDSA”，将其用作“alg”参数的值。
The following key subtypes are defined here for use with EdDSA:
此处定义了以下用于EdDSA的键子类型：
"crv" EdDSA Variant Ed25519 Ed25519 Ed448 Ed448
“crv”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瞬时静态（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”）。
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签名。所有输入和输出均为八位字符串。
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签名（作为签名）来执行验证。所有输入都是八位字符串。如果算法接受，则签名有效；否则，签名无效。
The following key subtypes are defined here for purpose of "Key Agreement with Elliptic Curve Diffie-Hellman Ephemeral Static" (ECDH-ES):
为了“椭圆曲线Diffie-Hellman瞬时静态密钥协议”（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”。这些子类型不能用于签名。
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”。
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:
密钥协商的Z值（原始密钥协商输出）（根据[RFC7518]第4.6.2节在后续密钥派生函数（KDF）中使用）确定如下：
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.
将适当的ECDH函数应用于临时私钥（作为标量输入）和接收器公钥（作为u坐标输入）。输出是Z值。所有输入和输出均为八位字符串。
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算法（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位对称加密（尤其是密钥包装和加密）。
The following has been added to the "JSON Web Key Types" registry:
以下内容已添加到“JSON Web密钥类型”注册表中：
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
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键参数”注册表中：
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参数信息类：与“kty”值一起使用的公共o:“OKP”o更改控制器：IESG o规范文件：RFC 8037第2节
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参数信息类：与“kty”值一起使用的私钥o:“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
o 参数名称：“x”o参数说明：公钥o参数信息类：与“kty”值一起使用的公共o:“OKP”o变更控制器：IESG o规范文件：RFC 8037第2节
The following has been added to the "JSON Web Signature and Encryption Algorithms" registry:
“JSON Web签名和加密算法”注册表中添加了以下内容：
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 o算法分析文件第3.1节：[RFC8032]
The following has been added to the "JSON Web Key Elliptic Curve" registry:
“JSON Web密钥椭圆曲线”注册表中添加了以下内容：
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实现要求：可选o更改控制器：IESG o规范文件：RFC 8037 o分析文件第3.2节：[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执行要求：可选o更改控制器：IESG o规范文件：RFC 8037 o分析文件第3.2节：[RFC7748]
[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.，“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]Jones，M.，Bradley，J.和N.Sakimura，“JSON网络签名（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]Jones，M.，“JSON Web密钥（JWK）”，RFC 7517，DOI 10.17487/RFC75172015年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]Jones，M.，“JSON网络算法（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]Jones，M.和N.Sakimura，“JSON网络密钥（JWK）指纹”，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，“爱德华兹曲线数字签名算法（EdDSA）”，RFC 8032，DOI 10.17487/RFC8032，2017年1月<http://www.rfc-editor.org/info/rfc8032>.
[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]Jones，M.和J.Hildebrand，“JSON Web加密（JWE）”，RFC 7516，DOI 10.17487/RFC7516，2015年5月<http://www.rfc-editor.org/info/rfc7516>.
To the extent possible, these examples use material taken from test vectors of [RFC7748] and [RFC8032].
在可能的范围内，这些示例使用取自[RFC7748]和[RFC8032]测试向量的材料。
{"kty":"OKP","crv":"Ed25519",
"d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A",
"x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
{"kty":"OKP","crv":"Ed25519",
"d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A",
"x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
The hexadecimal dump of private key is:
私钥的十六进制转储为：
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
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
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
This is the public part of the previous private key (which just omits "d"):
这是前一个私钥的公共部分（仅省略“d”）：
{"kty":"OKP","crv":"Ed25519",
"x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
{"kty":"OKP","crv":"Ed25519",
"x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
The JWK Thumbprint canonicalization of the two examples above (with a linebreak inserted for formatting reasons) is:
上面两个示例的JWK指纹规范化（由于格式原因插入了换行符）是：
{"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI
aaPcHURo"}
{"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".
它的SHA-256散列（十六进制）为90FACAFEA9B1556698540F70C0117A22EA37BD5CF3CED347093C1707282B4B89，这导致“kPrK_qmxvwayva9WWBF6IUO3VVVZZ7TXHTWxBYGRS4K”的base64url编码JWK指纹表示。
The JWS protected header is:
JWS受保护的标头是：
{"alg":"EdDSA"}
{"alg":"EdDSA"}
This has the base64url encoding of:
其base64url编码为：
eyJhbGciOiJFZERTQSJ9
EYJHBGCOIJFZERTQSJ9
The payload is (text):
有效载荷为（文本）：
Example of Ed25519 signing
Ed25519签名示例
This has the base64url encoding of:
其base64url编码为：
RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
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
eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
Applying the Ed25519 signing algorithm using the private key, public key, and the JWS signing input yields the signature (hex):
使用私钥、公钥和JWS签名输入应用Ed25519签名算法可生成签名（十六进制）：
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
86 0c 98 d2 29 7f 30 60 a3 3f 42 73 96 72 d6 1b 53 cf 3a de fe d3 c6 72 f3 20 dc 02 1b 41 1e 9d 59 b8 62 8d c3 51 e2 48 b8 8b 29 46 8e 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
hgyY0il_mgcjp0jzlnlwg1pot7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt 9g7svpar_mumokag
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
EYJHBBGCIOIJFZERTQSJ9.RXHHBXBSSBVZIBZDI1NTE5IHNPZ25PBMC.hgyY0il_-MGCj P0JzlnLWG1PPOt7-09PGCVMG3AIBQR6DWBHIJCNR4KI4IYLGJG5BHVSPT9G7SVPAR_Mu M0KAg
The JWS from the example above is:
上述示例中的JWS是：
eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu M0KAg
EYJHBBGCIOIJFZERTQSJ9.RXHHBXBSSBVZIBZDI1NTE5IHNPZ25PBMC.hgyY0il_-MGCj P0JzlnLWG1PPOt7-09PGCVMG3AIBQR6DWBHIJCNR4KI4IYLGJG5BHVSPT9G7SVPAR_Mu M0KAg
This has 2 dots in it, so it might be valid a JWS. Base64url decoding the protected header yields:
这里面有两个点，所以它可能是一个有效的JWS。Base64url解码受保护的标头会产生：
{"alg":"EdDSA"}
{"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:
签名输入是第二个点之前的部分：
eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
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签名示例
The public key to encrypt to is:
要加密的公钥为：
{"kty":"OKP","crv":"X25519","kid":"Bob",
"x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"}
{"kty":"OKP","crv":"X25519","kid":"Bob",
"x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"}
The public key from the target key is (hex):
目标密钥的公钥为（十六进制）：
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 d3 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):
短暂的秘密恰好是（十六进制）：
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
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）（十六进制）：
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
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:
这表示为临时公钥值：
{"kty":"OKP","crv":"X25519",
"x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}
{"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"}
{"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）（十六进制）：
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
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
The receiver computes the DH Z value as X25519(seckey, ephkey_pub) (hex):
接收器将DH Z值计算为X25519（seckey，ephkey_pub）（十六进制）：
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
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
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运行该值）。
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"}
{"kty":"OKP","crv":"X448","kid":"Dave",
"x":"PreoKbDNIPW8_AtZm2_sz22kYnEHvbDU80W0MCfYuXL8PjT7QjKhPKcG3LV67D2
uB73BxnvzNgk"}
The public key from the target key is (hex):
目标密钥的公钥为（十六进制）：
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
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):
短暂的秘密恰好是（十六进制）：
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
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):
因此临时公钥是X448（ephkey，G）（十六进制）：
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
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"}
{"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"}
{"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）（十六进制）：
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
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 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 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）（十六进制）：
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
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 2b b6 0c 0b 56 fd 24 64 c3 35 54 39 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.
感谢马特·米勒的编辑帮助。
Author's Address
作者地址
Ilari Liusvaara Independent
Ilari Liusvaara独立报
Email: ilariliusvaara@welho.com
Email: ilariliusvaara@welho.com