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

quot;}

   This has the base64url encoding of:

   eyJhbGciOiJFZERTQSJ9

   The payload is (text):

   Example of Ed25519 signing

   This has the base64url encoding of:

   RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc

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

   eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc

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

   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:

   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):

   eyJhbGciOiJFZERTQSJ9.RXhhbXBsZSBvZiBFZDI1NTE5IHNpZ25pbmc.hgyY0il_MGCj
   P0JzlnLWG1PPOt7-09PGcvMg3AIbQR6dWbhijcNR4ki4iylGjg5BhVsPt9g7sVvpAr_Mu
   M0KAg

Liusvaara                    Standards Track                   [Page 10]
RFC 8037            CFRG ECDH and Signatures in JOSE        January 2017

A.5.  Ed25519 Validation

   The JWS from the example above is:

   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:

   {"alg":"EdDSA"}

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

   The signing input is the part before the second dot:

   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:

   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 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

   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

Liusvaara                    Standards Track                   [Page 11]
RFC 8037            CFRG ECDH and Signatures in JOSE        January 2017

   This is represented as the ephemeral public key value:

   {"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):

   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):

   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).

A.7.  ECDH-ES with 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):

   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

Liusvaara                    Standards Track                   [Page 12]
RFC 8037            CFRG ECDH and Signatures in JOSE        January 2017

   So the ephemeral public key is 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):

   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):

   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).

Liusvaara                    Standards Track                   [Page 13]
RFC 8037            CFRG ECDH and Signatures in JOSE        January 2017

Acknowledgements

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

   Thanks to Matt Miller for some editorial help.

Author's Address

   Ilari Liusvaara
   Independent

   Email: ilariliusvaara@welho.com

Liusvaara                    Standards Track                   [Page 14]