Re: [jose] CFRG ECC in JOSE - thumbprint

[Anders Rundgren <[e-mail]>]

Confusing or not, I like it and hope to implement at least
Ed25519 in the next couple of months.

Anders

On 2015-11-18 20:31, Ilari Liusvaara wrote:
> On Wed, Nov 18, 2015 at 12:27:12AM +0000, Mike Jones wrote:
>> I would strongly argue for using "crv" and "x" to characterize these
>> algorithms.  Developers will be unpleasantly surprised if we don't
>> and more than likely unnecessarily confused as well.
>
> Well, I changed the text to use "crv" and "x" instead of "kag" and "p"
> (and also changed "key algorithm group" to "key subtype", now from
> EC registry, instead of algorithm registry).
>
> As to confusion potential, I would say this is more confusing as it
> uses the same parameter name for two quite different uses.
>
>> I'm on the fence about whether to use "kty":"EC" or a new key type
>> value, such as "EC1" (Elliptic Curve with one coordinate).  I'll
>> note that "EC" is already designed to allow curves whose
>> representations use "x" but not "y", so there's strictly speaking no
>> need for a new key type.  But I understand the argument that since
>> "x" isn't represented in SEC1 format for these curves, that a
>> different "kty" value may be appropriate.
>
> Well, I kept the "OKP" name as I think it better describes what these
> things are about than "EC1".
>
> As for "EC", there is no guarantee these work for various ECC
> algorithms one would expect to work for every curve (e.g. X25519 won't
> work for signing, Ed25519 won't work for anything that presently
> exists).
>
> -----------------------------------------------------------------------
> Network Working Group                                       I. Liusvaara
> Internet-Draft                                               Independent
> Intended status: Standards Track                       November 18, 2015
> Expires: May 21, 2016
>
>
>                     CFRG curves and signatures in JOSE
>                      draft-liusvaara-jose-cfrg-curves
>
> Abstract
>
>     This document defines how to use curves and algorithms from IRTF CFRG
>     elliptic curves work (Diffie-Hellman and signatures) in JOSE.
>
> Status of This Memo
>
>     This Internet-Draft is submitted in full conformance with the
>     provisions of BCP 78 and BCP 79.
>
>     Internet-Drafts are working documents of the Internet Engineering
>     Task Force (IETF).  Note that other groups may also distribute
>     working documents as Internet-Drafts.  The list of current Internet-
>     Drafts is at http://datatracker.ietf.org/drafts/current/.
>
>     Internet-Drafts are draft documents valid for a maximum of six months
>     and may be updated, replaced, or obsoleted by other documents at any
>     time.  It is inappropriate to use Internet-Drafts as reference
>     material or to cite them other than as "work in progress."
>
>     This Internet-Draft will expire on May 21, 2016.
>
> Copyright Notice
>
>     Copyright (c) 2015 IETF Trust and the persons identified as the
>     document authors.  All rights reserved.
>
>     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.
>
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 1]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> Table of Contents
>
>     1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
>       1.1.  Requirements Terminology  . . . . . . . . . . . . . . . .   2
>       1.2.  Notation  . . . . . . . . . . . . . . . . . . . . . . . .   2
>     2.  Key type 'OKP'  . . . . . . . . . . . . . . . . . . . . . . .   3
>     3.  Algorithms  . . . . . . . . . . . . . . . . . . . . . . . . .   3
>       3.1.  Signatures  . . . . . . . . . . . . . . . . . . . . . . .   3
>         3.1.1.  Algorithms  . . . . . . . . . . . . . . . . . . . . .   3
>         3.1.2.  Signing . . . . . . . . . . . . . . . . . . . . . . .   4
>         3.1.3.  Verification  . . . . . . . . . . . . . . . . . . . .   4
>       3.2.  ECDH-ES . . . . . . . . . . . . . . . . . . . . . . . . .   4
>         3.2.1.  Performing the ECDH operation . . . . . . . . . . . .   4
>     4.  Security considerations . . . . . . . . . . . . . . . . . . .   4
>     5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
>     6.  IANA considerations . . . . . . . . . . . . . . . . . . . . .   5
>     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
>       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
>       7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
>     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   8
>       A.1.  Ed25519 private key . . . . . . . . . . . . . . . . . . .   8
>       A.2.  Ed25519 public key  . . . . . . . . . . . . . . . . . . .   9
>       A.3.  JWK thumbprint canonicalization . . . . . . . . . . . . .   9
>       A.4.  Ed25519 Signing . . . . . . . . . . . . . . . . . . . . .   9
>       A.5.  Ed25519 Validation  . . . . . . . . . . . . . . . . . . .  10
>       A.6.  ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . .  11
>     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  12
>
> 1.  Introduction
>
>     Internet Research Task Force (IRTF) Crypto Forum Research Group
>     (CFRG) selected new elliptic curves and signature algorithms for
>     asymmetric key cryptography.  This document defines how those curves
>     and algorithms are to be used in JOSE in interoperable manner.
>
>     This extends [RFC7517] and [RFC7518]
>
> 1.1.  Requirements Terminology
>
>     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].
>
> 1.2.  Notation
>
>     All inputs to and outputs from the the ECDH and signature functions
>     are defined to be octet strings, with the exception of output of
>     verfication function, which is a boolean.
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 2]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> 2.  Key type '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:
>
>     o  The parameter "kty" MUST be "OKP".
>
>     o  The parameter "crv" MUST be present, and contain the subtype of
>        the key (from "JSON Web Elliptic curve" registry).
>
>     o  The parameter "x" MUST be present, and contain the public key
>        encoded using base64url [RFC4648] encoding.
>
>     o  The parameter "d" MUST be present for private keys, and contain
>        the private key encoded using base64url encoding.  This parameter
>        MUST NOT be present for public keys.
>
>     Note: Do not assume that there is an underlying elliptic curve,
>     despite the existence of the "crv" and "x" parameters.
>
>     When calculating thumbprints [RFC7638], the three public key fields
>     are included in the hash.  That is, in lexographic order: "crv",
>     "kty" and "x".
>
> 3.  Algorithms
>
> 3.1.  Signatures
>
> 3.1.1.  Algorithms
>
>     The following signature algorithms are defined here (to be applied as
>     values of "alg" parameter).  All these have keys with subtype of the
>     same name:
>
>       alg value:  subtype:     The algorithm:
>       Ed25519     Ed25519      Ed25519
>       Ed25519ph   Ed25519ph    Ed25519ph
>       Ed448       Ed448        Ed448
>       Ed448ph     Ed448ph      Ed448ph
>
>     The key type for these keys is "OKP" and key subtype for these
>     algorithms MUST be the same as the algorithm name.
>
>     The keys of these subtypes MUST NOT be used for ECDH-ES.
>
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 3]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> 3.1.2.  Signing
>
>     Signing for these is preformed by applying the signing algorithm
>     defined in [I-D.irtf-cfrg-eddsa] 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 value.  All inputs and
>     outputs are octet strings.
>
> 3.1.3.  Verification
>
>     Verification is performed by applying the verification algorithm
>     defined in [I-D.irtf-cfrg-eddsa] to the public key (as public key),
>     the JWS Signing Input (as message) and the JWS Signature value (as
>     signature).  All inputs are octet strings.  If the algorithm accepts,
>     the signature is valid, otherwise it is invalid.
>
> 3.2.  ECDH-ES
>
>     The following key subtypes defined here for purpose of ECDH-ES:
>
>        subtype:          ECDH Function:
>        X25519            X25519
>        X448              X448
>
>     The key type used with these keys is "OKP".  These subtypes MUST NOT
>     be used for signing.
>
> 3.2.1.  Performing the ECDH operation
>
>     The "x" parameter of "epk" field is set as follows:
>
>     Apply the appropriate ECDH function to the ephemeral private key (as
>     scalar input) and the standard basepoint (as u-coordinate input).
>     The output is the value for "x" parameter of "epk" field.  All inputs
>     and outputs are octet strings.
>
>     The Z value (raw key agreement output) for key agreement is
>     determined as follows:
>
>     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.
>
> 4.  Security considerations
>
>     Security considerations from [I-D.irtf-cfrg-curves] and
>     [I-D.irtf-cfrg-eddsa] apply here.
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 4]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     Some algorithms interact in bad ways (e.g.  "Ed25519" and
>     "Ed25519ph").  For this reason, those algorithms have different
>     subtypes, so keys for each are not mixed up.
>
>     Do not separate key material from information what key algorithm
>     group it is for.  When using keys, check that the algorithm is
>     compatible with the key algorithm group for the key.  To do otherwise
>     opens system up to attacks via mixing up algorithms.  It is
>     practicularly dangerous to mix up signature and MAC algorithms.
>
>     Do not assume that signature also binds the key used for signing, it
>     does not (there are also other widespread signature algorithms where
>     this binding fails, as such binding is not part of the definition of
>     secure signature primitive).  As an example of such failure, the
>     Ed25519ph signature of X under key (Ed25519ph,Y) is identical to
>     Ed25519 signature of SHA512(X) under key (Ed25519,Y).  And often it
>     takes only setting a few bits of message (easy to do by brute force)
>     to make the message valid enough to be processed in some very
>     surprising way.
>
>     If key generation or batch signature verification is performed, a
>     well-seed cryptographical random number generator is REQUIRED.
>     Signing and non-batch signature verification are deterministic
>     operations and do not need random numbers of any kind.
>
> 5.  Acknowledgements
>
>     Mike Jones for comments on initial pre-draft.
>
> 6.  IANA considerations
>
>     The following is added to JSON Web Key Types Registry:
>
>     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-THIS]
>
>
>     The following is added to JSON Web Key Parameters Registry:
>
>     o  Parameter Name: "crv"
>     o  Parameter Description: The algorithm group of keypair
>     o  Parameter Information Class: Public
>     o  Used with "kty" Value(s): "OKP"
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 2 of [RFC-THIS]
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 5]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     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-THIS]
>
>     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-THIS]
>
>
>     The following is added to JSON Web Signature and Encryption
>     Algorithms Registry:
>
>     o  Algorithm Name: "Ed25519"
>     o  Algorithm Description: Ed25519 signature algorithm
>     o  Algorithm Usage Location(s): "alg"
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa]
>
>     o  Algorithm Name: "Ed25519ph"
>     o  Algorithm Description: Ed25519 signature algorithm with prehash
>     o  Algorithm Usage Location(s): "alg"
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa]
>
>     o  Algorithm Name: "Ed448"
>     o  Algorithm Description: Ed448 signature algorithm
>     o  Algorithm Usage Location(s): "alg"
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa]
>
>     o  Algorithm Name: "Ed448ph"
>     o  Algorithm Description: Ed448 signature algorithm with prehash
>     o  Algorithm Usage Location(s): "alg"
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 6]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-eddsa]
>
>
>     The following is added to JSON Web Key Elliptic Curve Registry:
>
>     o  Curve Name: "Ed25519"
>     o  Curve Description: Ed25519 signature algorithm keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>
>     o  Curve Name: "Ed25519ph"
>     o  Curve Description: Ed25519 signature algorithm with prehash
>        keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>
>     o  Curve Name: "Ed448"
>     o  Curve Description: Ed448 signature algorithm keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>
>     o  Curve Name: "Ed448ph"
>     o  Curve Description: Ed448 signature algorithm with prehash keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.1 of [RFC-THIS]
>
>     o  Curve name: "X25519"
>     o  Curve Description: X25519 function keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.2 of [RFC-THIS]
>     o  Analysis Documents(s): [I-D.irtf-cfrg-curves]
>
>     o  Curve Name: "X448"
>     o  Curve Description: X448 function keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.2 of [RFC-THIS]
>     o  Analysis Documents(s): [I-D.irtf-cfrg-curves]
>
>
>
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 7]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> 7.  References
>
> 7.1.  Normative References
>
>     [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>.
>
>     [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>.
>
>     [I-D.irtf-cfrg-curves]
>                Langley, A. and M. Hamburg, "Elliptic Curves for
>                Security", draft-irtf-cfrg-curves-09 (work in progress),
>                September 2015.
>
>     [I-D.irtf-cfrg-eddsa]
>                Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
>                Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-00
>                (work in progress), October 2015.
>
> 7.2.  Informative References
>
>     [RFC7517]  Jones, M., "JSON Web Key (JWK)", RFC 7517, DOI 10.17487/
>                RFC7517, May 2015,
>                <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>.
>
>     [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>.
>
> Appendix A.  Examples
>
>     To the extent possible, the examples use material lifted from test
>     vectors of [I-D.irtf-cfrg-curves] and [I-D.irtf-cfrg-eddsa]
>
> A.1.  Ed25519 private key
>
>     {"kty":"OKP","crv":"Ed25519",
>     "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A"
>     "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 8]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     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
>
>     And of the public key:
>
>     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
>
>     This is the public parts of the previous private key (just omits
>     "d"):
>
>     {"kty":"OKP","crv":"Ed25519",
>     "x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
>
> A.3.  JWK thumbprint canonicalization
>
>     The JWK thumbprint canonicalization of the two above examples is
>     (linebreak inserted for formatting reasons)
>
>     {"crv":"Ed25519","kty":"OKP","x":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI
>     aaPcHURo"}
>
>     Which has the SHA-256 hash of:
>     90facafea9b1556698540f70c0117a22ea37bd5cf3ed3c47093c1707282b4b89
>
> A.4.  Ed25519 Signing
>
>     The JWS protected header is:
>
>     {"alg":"Ed25519"}
>
>     This has base64url encoding of:
>
>     eyJhbGciOiJFZDI1NTE5In0
>
>     The payload is (text):
>
>     Example of Ed25519 signing
>
>     This has base64url encoding of:
>
>     RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                  [Page 9]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     The JWS signing input is (concatenation of base64url encoding of the
>     (protected) header, a dot and base64url encoding of the payload) is:
>
>     eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
>
>     Applying Ed25519 signing algorithm to the private key, public key and
>     the JWS signing input yields signature (hex):
>
>     53 18 48 60 b1 c6 83 7f 4d 54 22 e9 40 05 43 fd
>     47 1f 3a 69 c6 48 2c cb 15 9a 17 62 42 e2 21 b1
>     5c 72 63 9b fe a3 9b b2 08 f3 2c ab 1f 27 0f b8
>     36 57 1c 52 0b d8 ac 41 eb 45 b3 55 d0 77 19 01
>
>     Converting this to base64url yields:
>
>     UxhIYLHGg39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccU
>     gvYrEHrRbNV0HcZAQ
>
>     So the compact serialization of JWS is (concatenation of signing
>     input, a dot and base64url encoding of the signature:
>
>     eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.UxhIYLHGg
>     39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccUgvYrEHrRb
>     NV0HcZAQ
>
> A.5.  Ed25519 Validation
>
>     The JWS from above example is:
>
>     eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.UxhIYLHGg
>     39NVCLpQAVD_UcfOmnGSCzLFZoXYkLiIbFccmOb_qObsgjzLKsfJw-4NlccUgvYrEHrRb
>     NV0HcZAQ
>
>     This has 2 dots in it, so it might be valid JWS.  Base64url decoding
>     the protected header yields:
>
>     {"alg":"Ed25519"}
>
>     So this is Ed25519 signature.  Now the key has: "kty":"OKP" and
>     "crv":"Ed25519", so the key is valid for the algorithm (if it had
>     other values, the validation would have failed).
>
>     The signing input is the part before second dot:
>
>     eyJhbGciOiJFZDI1NTE5In0.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc
>
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                 [Page 10]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     Applying Ed25519 verification algorithm to the public key, JWS
>     signing input and the signature yields true.  So the signature is
>     valid.  The message is base64 decoding of the part between the dots:
>
>     Example of Ed25519 signing
>
> A.6.  ECDH-ES with X25519
>
>     The public key to encrypt to is:
>
>     {"kty":"OKP","crv":"X25519","kid":"Bob"
>     "x":"3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08"}
>
>     The public key from 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
>
>     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
>
>     So the ephemeral public key is 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 packed into ephemeral public key value:
>
>     {"kty":"OKP","crv":"X25519",
>     "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}
>
>     So the protected header could for example be:
>
>     {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","crv":"X25519",
>     "x":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"},
>     "enc":"A128GCM","kid":"Bob"}
>
>     And sender computes as the DH Z value as 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
>
>     The receiver computes as the DH Z value as X25519(seckey,ephkey_pub)
>     (hex):
>
>
>
>
> Liusvaara                 Expires May 21, 2016                 [Page 11]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     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
>
>     Which is the same as sender's value (the both sides run this through
>     KDF before using as AES128-KW key).
>
> Author's Address
>
>     Ilari Liusvaara
>     Independent
>
>     Email: [e-mail]
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Liusvaara                 Expires May 21, 2016                 [Page 12]
> -----------------------------------------------------------------------
>
>
> -Ilari
>