Re: [jose] CFRG ECC in JOSE - thumbprint

[Anders Rundgren <[e-mail]>]

Hi Ilari,

If these curves are generally recognized as "Edwards" (?) I would personally prefer
that "kty" refer to something Edward-ish like "ED" although this is (of course)
entirely unimportant.

However, for the other parameters I don't see much value in creating new JOSE
"keywords" unless we are dealing with things that have no previous counterpart.

Simon's PKIX I-Ds talk about "curves" so "crv" should IMHO apply here as well.

Reusing "x" wouldn't be a crime either since each "kty" must be treated separately anyway.

Anders
for the "art club" :-)


On 2015-11-14 14:10, Ilari Liusvaara wrote:
> On Wed, Nov 11, 2015 at 10:37:33AM +0200, Ilari Liusvaara wrote:
>> On Tue, Nov 10, 2015 at 08:22:53PM -0500, Justin Richer wrote:
>>> I would lean toward using a new “kty” value for these as the syntax
>>> is different from existing ones. This will help parsers and existing
>>> implementations add this in without adding special processing rules:
>>> code is already set up to branch on “kty” so let’s keep that
>>> behavior. Note you can still reuse parts of the key definition
>>> (like “d” is found in both RSA and EC keypairs) without having to
>>> overload a new syntax since the kty defines a new namespace,
>>> effectively. I suggest a value of “ED” since they’re all “edwards”
>>> curves from my quick read.
>>
>> 1) Actually, I think "okp" (Octet Key Pair) or something like that
>> might be more descriptive, since these are keypairs with no structure
>> outside the box ("oct" or whatever won't do, since that's symmetric,
>> not asymmetric). This also holds for X25519 and X448.
>
> Well, here is a pre-draft version using new key type (for algorithms
> using octet-string key pairs). I named the analog of the EC "curve"
> parameter as "key algorithm group".
>
> The crypto material in examples are either from CFRG document examples
> or from my vector generator for Ed25519.
>
> The naming could probably be improved...
>
>
> -----------------------------------------------------------------------
> Network Working Group                                       I. Liusvaara
> Internet-Draft                                               Independent
> Intended status: Standards Track                       November 14, 2015
> Expires: May 17, 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 17, 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 17, 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 . . . . . . . . . . . . . . . . . . . . . . .   3
>         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  . . . . . . . . . . . . . . . . . . . . . . . . .   7
>       7.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
>       7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
>     Appendix A.  Examples . . . . . . . . . . . . . . . . . . . . . .   8
>       A.1.  Ed25519 private key . . . . . . . . . . . . . . . . . . .   8
>       A.2.  Ed25519 public key  . . . . . . . . . . . . . . . . . . .   8
>       A.3.  JWK thumbprint canonicalization . . . . . . . . . . . . .   8
>       A.4.  Ed25519 Signing . . . . . . . . . . . . . . . . . . . . .   9
>       A.5.  Ed25519 Validation  . . . . . . . . . . . . . . . . . . .   9
>       A.6.  ECDH-ES with X25519 . . . . . . . . . . . . . . . . . . .  10
>     Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  11
>
> 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 17, 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 "kag" MUST be present, and contain the key algorithm
>        group (from JSON Web Signature and Encryption Algorithms).
>
>     o  The parameter "p" 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.
>
>     When calculating thumbprints [RFC7638], the three public key fields
>     are included in the hash.  That is, in lexographic order: "kag",
>     "kty" and "p".
>
> 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 algorithm group
>     of the same name:
>
>       alg/kag value:     The algorithm:
>       Ed25519            Ed25519
>       Ed25519ph          Ed25519ph
>       Ed448              Ed448
>       Ed448ph            Ed448ph
>
>     The key type for these keys is "OKP" and key algorithm group for
>     these algorithms MUST be the same as the algorithm name.
>
> 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.
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 3]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> 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 algorithm groups are defined here for purpose of
>     ECDH-ES:
>
>        algorithm group:  ECDH Function:
>        X25519            X25519
>        X448              X448
>
>     The key type used with these keys is "OKP".
>
> 3.2.1.  Performing the ECDH operation
>
>     The "p" 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 "p" 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.
>
>     Some algorithms interact in bad ways (e.g.  "Ed25519" and
>     "Ed25519ph").  For this reason, those algorithms have different
>     algorithm groups, 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
>
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 4]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     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: "kag"
>     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]
>
>     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]
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 5]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     The following is added to JSON Web Key Parameters Registry:
>
>     o  Parameter Name: "p"
>     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 and its
>        keypairs
>     o  Algorithm Usage Location(s): "alg", "kag"
>     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
>        and its keypairs
>     o  Algorithm Usage Location(s): "alg", "kag"
>     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 and its keypairs
>     o  Algorithm Usage Location(s): "alg", "kag"
>     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 and
>        its keypairs
>     o  Algorithm Usage Location(s): "alg", "kag"
>     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]
>
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 6]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     o  Algorithm Name: "X25519"
>     o  Algorithm Description: X25519 function keypairs
>     o  Algorithm Usage Location(s): "kag"
>     o  JOSE Implementation Requirements: Optional
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.2 of [RFC-THIS]
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-curves]
>
>     o  Class Name: "X448"
>     o  Class Description: X448 function keypairs
>     o  JOSE Implementation Requirements: Optional
>     o  Algorithm Usage Location(s): "kag"
>     o  Change Controller: IESG
>     o  Specification Document(s): Section 3.2 of [RFC-THIS]
>     o  Algorithm Analysis Documents(s): [I-D.irtf-cfrg-curves]
>
> 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>.
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 7]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     [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","kag":"Ed25519",
>     "d":"nWGxne_9WmC6hEr0kuwsxERJxWl7MmkZcDusAxyuf2A"
>     "p":"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
>
>     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","kag":"Ed25519",
>     "p":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwIaaPcHURo"}
>
> A.3.  JWK thumbprint canonicalization
>
>     The JWK thumbprint canonicalization of the two above examples is
>     (linebreak inserted for formatting reasons)
>
>     {"kag":"Ed25519","kty":"OKP","p":"11qYAYKxCrfVS_7TyWQHOg7hcvPapiMlrwI
>     aaPcHURo"}
>
>     Which has the SHA-256 hash of:
>     9b4dece50b24e8008ea629f8b0443f785c910fe2d6fd9c058a8032a54ae8ed97
>
>
>
>
>
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 8]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
> 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
>
>     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:
>
>
>
>
>
> Liusvaara                 Expires May 17, 2016                  [Page 9]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     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
>     "kag":"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
>
>     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","kag":"X25519","kid":"Bob"
>     "p":"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:
>
>
>
>
>
> Liusvaara                 Expires May 17, 2016                 [Page 10]
> 
> Internet-Draft     CFRG curves and signatures in JOSE      November 2015
>
>
>     {"kty":"OKP","kag":"X25519",
>     "p":"hSDwCYkwp1R0i33ctD73Wg2_Og0mOBr066SpjqqbTmo"}
>
>     So the protected header could for example be:
>
>     {"alg":"ECDH-ES+A128KW","epk":{"kty":"OKP","kag":"X25519",
>     "p":"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):
>
>     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 17, 2016                 [Page 11]
> -----------------------------------------------------------------------
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose
>