| Network Working Group | N. Madden |
| Internet-Draft | ForgeRock |
| Intended status: Standards Track | May 10, 2019 |
| Expires: November 11, 2019 |
Public Key Authenticated Encryption for JOSE: ECDH-1PU
draft-madden-jose-ecdh-1pu-01
This document describes the ECDH-1PU public key authenticated encryption algorithm for JWE. The algorithm is similar to the existing ECDH-ES encryption algorithm, but adds an additional ECDH key agreement between static keys of the sender and recipient. This additional step allows the recipient to be assured of sender authenticity without requiring a nested signed-then-encrypted message structure. The mode is also a useful building block for constructing interactive handshake protocols on top of JOSE.
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 https://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 November 11, 2019.
Copyright (c) 2019 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 (https://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.
JSON Object Signing and Encryption (JOSE) defines a number of encryption (JWE) [RFC7516] and digital signature (JWS) [RFC7515] algorithms. When symmetric cryptography is used, JWE provides authenticated encryption that ensures both confidentiality and sender authentication. However, for public key cryptography the existing JWE encryption algorithms provide only confidentiality and some level of ciphertext integrity. When sender authentication is required, users must resort to nested signed-then-encrypted structures, which increases the overhead and size of resulting messages. This document describes an alternative encryption algorithm called ECDH-1PU that provides public key authenticated encryption, allowing the benefits of authenticated encryption to be enjoyed for public key JWE as it currently is for symmetric cryptography.
ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve Diffie-Hellman key agreement described in [NIST.800-56A].
The advantages of public key authenticated encryption with ECDH-1PU compared to using nested signed-then-encrypted documents include the following:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC8174] when, and only when, they appear in all capitals, as shown here.
This section defines the specifics of key agreement with Elliptic Curve Diffie-Hellman One-Pass Unified Model, in combination with the one-step KDF, as defined in Section 5.8.2.1 of [NIST.800-56A] using the Concatenation Format of Section 5.8.2.1.1. This is identical to the ConcatKDF function used by the existing JWE ECDH-ES algorithm defined in Section 4.6 of [RFC7518]. As for ECDH-ES, the key agreement result can be used in one of two ways:
A new ephemeral public key value MUST be generated for each key agreement operation.
In Direct Key Agreement mode, the output of the KDF MUST be a key of the same length as that used by the "enc" algorithm. In this case, the empty octet sequence is used as the JWE Encrypted Key value. The "alg" (algorithm) Header Parameter value "ECDH-1PU" is used in Direct Key Agreement mode.
In Key Agreement with Key Wrapping mode, the output of the KDF MUST be a key of the length needed for the specified key wrapping algorithm. In this case, the JWE Encrypted Key is the CEK wrapped with the agreed-upon key.
The following "alg" (algorithm) Header Parameter values are used to indicate the JWE Encrypted Key is the result of encrypting the CEK using the result of the key agreement algorithm as the key encryption key for the corresponding key wrapping algorithm:
| "alg" Param Value | Key Management Algorithm |
|---|---|
| ECDH-1PU+A128KW | ECDH-1PU using one-pass KDF and CEK wrapped with "A128KW" |
| ECDH-1PU+A192KW | ECDH-1PU using one-pass KDF and CEK wrapped with "A192KW" |
| ECDH-1PU+A256KW | ECDH-1PU using one-pass KDF and CEK wrapped with "A256KW" |
The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and "apv" (Agreement PartyVInfo) header parameters are used in ECDH-1PU exactly as defined in Section 4.6.1 of [RFC7518].
When no other values are supplied, it is RECOMMENDED that the producer software initializes the "apu" header to the base64url-encoding of the SHA-256 hash of the concatenation of the sender's static public key and the ephemeral public key, and the "apv" header to the base64url-encoding of the SHA-256 hash of the recipient's static public key. This ensures that all keys involved in the key agreement are cryptographically bound to the derived keys.
A new Header Parameter "skid" (Sender Key ID) is registered as a hint as to which of the sender's keys was used to authenticate the JWE. The structure of the "skid" value is unspecified. Its value MUST be a case-sensitive string. Use of this Header Parameter is OPTIONAL. When used with a JWK, the "skid" value is used to match a JWK "kid" parameter value.
The key derivation process derives the agreed-upon key from the shared secret Z established through the ECDH algorithm, per Section 6.2.1.2 of [NIST.800-56A]. For the NIST prime order curves "P-256", "P-384", and "P-521", the ECC CDH primitive for cofactor Diffie-Hellman defined in Section 5.7.1.2 of [NIST.800-56A] is used (taking note that the cofactor for all these curves is 1). For curves "X25519" and "X448" the appropriate ECDH primitive from Section 5 of [RFC7748] is used.
Key derivation is performed using the one-step KDF, as defined in Section 5.8.1 and Section 5.8.2.1 of [NIST.800-56A] using the Concatenation Format of Section 5.8.2.1.1, where the Auxilary Function H is SHA-256. The KDF parameters are set as follows: [NIST.800-56A] need to provide values that meet the requirements of that doucument, e.g., by using values that identify the producer and consumer.
Applications need to specifiy how the "apu" and "apv" Header Parameters are used for that application. The "apu" and "apv" values MUST be distinct, when used. Applications wishing to conform to
See Appendix A for an example key agreement computation using this method.
A party that has received a JWE encrypted with ECDH-1PU MAY reply to that message by creating a new JWE using ECDH-1PU, but using the ephemeral public key ("epk") from the first message as if it was the originating party's static public key. In this case, key agreement proceeds exactly as for Section 2, but with the originator's ephemeral public key used as the recipient (Party V) static public key. The "alg" (algorithm) Header Parameter in the response MUST be identical to the "alg" Header Parameter of the original message. The "enc" (encryption method) Header Parameter in the response MUST also be identical to the "enc" Header Parameter of the original message.
The value of the "apu" (Agreement PartyUInfo) Header Parameter value from the original message SHOULD be reflected as the "apv" (Agreement PartyVInfo) Header Parameter value in the new message. Applications need to specify how the new "apu" Header Parameter should be constructed.
If a "kid" claim was included in the ephemeral public key of the original message, then a "kid" Header Parameter with the same value MUST be included in the reply JWE.
See Appendix B for an example handshake using this method.
After the initial message and a reply have been exchanged, the two parties may communicate using the derived key from the second message as the encryption key for any number of additional messages. Applications MUST specify the algorithm to be used. The JWE algorithm and encryption method used MUST use the same size key as the derived key. For example, if the derived key is 256-bits, then appropriate algorithms include alg=dir and enc=A256GCM, or alg=A256KW with any JWE content encryption method.
If Direct encryption is used, the "enc" (encryption method) of all subsequent messages MUST be identical to the "enc" Header Parameter of the handshake messages. If the same derived key is to be used for messages in both directions between the two parties, the application MUST specify how unique nonces/IVs are to be generated by each party to avoid collisions. It is RECOMMENDED that either a Key Wrap algorithm is used, or else the derived key is used as input to a key derivation function to derive separate keys for each direction.
This section registers identifiers under the IANA JSON Web Signature and Encryption Algorithms Registry established by [RFC7518] and the IANA JSON Web Signature and Encryption Header Parameters registry established by [RFC7515].
This section registers JWE algorithms as per the registry established in [RFC7518].
This section registers new Header Parameters as per the registry established in [RFC7515].
The security considerations of [RFC7516] and [RFC7518] relevant to ECDH-ES also apply to this specification.
The security considerations of [NIST.800-56A] apply here.
When performing an ECDH key agreement between a static private key and any untrusted public key, care should be taken to ensure that the public key is a valid point on the same curve as the private key. Failure to do so may result in compromise of the static private key. For the NIST curves P-256, P-384, and P-521, appropriate validation routines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the curves used by X25519 and X448, consult the security considerations of [RFC7748].
The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation (KCI) attacks. If the long-term static private key of a party is compromised, then the attacker can not only impersonate that party to other parties, but also impersonate any other party when communicating with the compromised party. The second and any subsequent messages in the two-way interactive handshake described in Section 3 are not vulnerable to KCI. If resistance to KCI is desired in a single message, then it is RECOMMENDED to use a nested JWS signature over the content.
When Key Agreement with Key Wrapping is used, with the same Content Encryption Key (CEK) reused for multiple recipients, any of those recipients can produce a new message that appears to come from the original sender. The new message will be indistinguishable from a genuine message from the original sender to any of the other participants. The sender SHOULD use a unique CEK for each recipient of a message.
The security properties of the one-pass unified model are given in Section 7.3 of [NIST.800-56A]. The ECDH-1PU scheme is also related (but not identical) to the "K" one-way handshake pattern of the Noise Protocol Framework. The two-way interactive handshake described in Section 3 is also related to the "KK" two-way interactive handshake pattern. The security properties of these handshake patterns are given in Section 7.7 of [Noise], although it should be stressed that many details differ between Noise and the current specification.
| [NIST.800-56A] | Barker, E., Chen, L., Roginsky, A., Vassilev, A. and R. Davis, "Recommendation for Pair-Wise Key Establishment Using Discrete Logarithm Cryptography Revision 3.", NIST Special Publication 800-56A, April 2018. |
| [RFC7515] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015. |
| [RFC7516] | Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015. |
| [RFC7518] | Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, DOI 10.17487/RFC7518, May 2015. |
| [RFC7748] | Langley, A., Hamburg, M. and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016. |
| [RFC8174] | Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017. |
| [Noise] | Perrin, T., "The Noise Protocol Framework, Revision 34", July 2018. |
| [PKAE] | An, J., "Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses", IACR ePrint 2001/079, 2001. |
| [RFC7519] | Jones, M., Bradley, J. and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015. |
| [RFC8037] | Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017. |
This example uses ECDH-1PU in Direct Key Agreement mode ("alg" value "ECDH-1PU") to produce an agreed-upon key for AES GCM with a 256-bit key ("enc" value "A256GCM"). The example re-uses the keys and parameters of the example computation in Appendix C of [RFC7518], with the addition of an extra static key-pair for Alice.
When used in this way, ECDH-1PU has similar security properties to the "K" one-way handshake pattern of [Noise], although it is quite different in details.
In this example, a producer Alice is encrypting content to a consumer Bob. Alice's static key-pair (in JWK format) used for the key agreement in this example (including the private part) is:
{"kty":"EC",
"crv":"P-256",
"x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis",
"y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE",
"d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"}
Bob's static key-pair (in JWK format) is:
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"}
The producer (Alice) generates an ephemeral key for the key agreement computation. Alice's ephemeral key (in JWK format) is:
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"}
Header Parameter values used in this example are as follows. The "apu" (agreement PartyUInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Alice" and the "apv" (agreement PartyVInfo) Header Parameter value is the base64url encoding of the UTF-8 string "Bob". The "epk" (ephemeral public key) Header Parameter is used to communicate the producer's (Alice's) ephemeral public key value to the consumer (Bob).
{"alg":"ECDH-1PU",
"enc":"A256GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
The resulting one-pass KDF [NIST.800-56A] parameter values are:
9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4
e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d
9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c
fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4
e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d
41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d
Concatenating the parameters AlgorithmID through SuppPrivInfo results in a FixedInfo value in Concatenation Format (as per Section 5.8.2.1.1 of [NIST.800-56A]) of (in hexidecimal notation):
00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41
6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00
Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value results in a one-pass KDF round 1 hash input of (hexadecimal):
00 00 00 01 9e 56 d9 1d 81 71 35 d3 72 83 42 83
bf 84 26 9c fb 31 6e a3 da 80 6a 48 f6 da a7 79
8c fe 90 c4 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c
68 8b 3e 7d 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12
41 ef d5 0d 00 00 00 07 41 32 35 36 47 43 4d 00
00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00
00 01 00
The resulting derived key, which is the full 256 bits of the round 1 hash output is:
6c af 13 72 3d 14 85 0a d4 b4 2c d6 dd e9 35 bf
fd 2f ff 00 a9 ba 70 de 05 c2 03 a5 e1 72 2c a7
The base64url-encoded representation of this derived key is:
bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc
This example use ECDH-1PU in Direct Key Agreement mode using the X448 curve from [RFC8037] to perform a two-way interactive handshake. When used in this way, ECDH-1PU has similar security properties to the "KK" interactive handshake pattern of [Noise]. Messages are encrypted using the "A256GCM" encryption method ("enc" Header Parameter value).
In this example, a producer Alice is encrypting content to a consumer Bob. Alice's static key-pair (in JWK format) including the private key part is (with linebreaks added for display purposes only):
{"kty":"OKP",
"kid":"alice-static",
"crv": "X448",
"x":"qaggoGo7qFwBrBtxv4hwI09UaiQmCrF1KdHvaXrzjzzInqDD0Cfx9GlGFi2367
RATs-hBoB2IHw",
"d":"hJW9knOYfyCIkZnW922U81uDNNfAwcVeNcpbaQIKyh0iW5LSpDLSmBdPSyvOh7
J4u9hArU2uoX0"}
Bob's static key-pair (in JWK format) including the private key part is (with linebreaks added for display purposes only):
{"kty":"OKP",
"kid":"bob-static",
"crv":"X448",
"x":"4jvO2Ef15DErhV5_5OzoaZDQ2tVb_jHB09eNruOkCTETatzOZ2EGgJCkXNElWR
sLnbns3TtYYSY",
"d":"HGKc9R7_Zso3BCnrhzA9GzOzHKHOkMYvb_n54aJ1qkO1qYYTEUS0OQmBZTq1NK
R5_kmiX5e5r-I"}
Alice generates an ephemeral key-pair for her handshake with Bob. Alice's ephemeral key-pair in JWK format is (with linebreaks added for display purposes only):
{"kty":"OKP",
"kid":"alice-ephemeral",
"crv":"X448",
"x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYBjS
XdwkLOIGKSI74",
"d":"8epzr7H0N7ZIIOZeNckLL3iAHfSmIDeb-cMSgI8PJzyQfjZB0tHoGFtkQG7cAK
xP0Fi6Bbfbe7I"}
The following JWE Protected Header is used for the message (with line breaks and whitespace added for display purposes):
{"typ":"JWT",
"epk":{
"kty":"OKP",
"crv":"X448",
"x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYB
jSXdwkLOIGKSI74"},
"apv":"Qm9i",
"apu":"QWxpY2U",
"kid":"bob-static",
"enc":"A256GCM",
"alg":"ECDH-1PU"}
After removing all whitespace, the octets of ASCII(BASE64URL(UTF8(JWE Protected Header))) are as follows (in hexadecimal notation):
65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69
4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35
49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32
49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69
4f 69 49 32 52 46 4a 34 55 32 56 74 59 55 64 57
65 44 46 70 56 6b 56 51 55 6e 6c 50 51 57 4e 55
53 31 4d 79 65 6b 70 7a 61 54 42 76 57 6a 6c 69
55 69 31 4a 61 46 70 56 53 6e 52 6c 65 6e 68 71
55 31 68 79 62 31 5a 76 52 46 52 6d 4c 56 4a 57
57 55 4a 71 55 31 68 6b 64 32 74 4d 54 30 6c 48
53 31 4e 4a 4e 7a 51 69 66 53 77 69 59 58 42 32
49 6a 6f 69 55 57 30 35 61 53 49 73 49 6d 46 77
64 53 49 36 49 6c 46 58 65 48 42 5a 4d 6c 55 69
4c 43 4a 72 61 57 51 69 4f 69 4a 69 62 32 49 74
63 33 52 68 64 47 6c 6a 49 69 77 69 5a 57 35 6a
49 6a 6f 69 51 54 49 31 4e 6b 64 44 54 53 49 73
49 6d 46 73 5a 79 49 36 49 6b 56 44 52 45 67 74
4d 56 42 56 49 6e 30
The resulting one-pass KDF [NIST.800-56A] parameter values are:
4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29
61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33
d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3
a5 d3 12 c7 9a 0c e1 47
d8 8e aa 18 61 a4 8e a4 69 7b e0 99 c6 bc 3b 73
4f 0e 13 6d ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0
e0 39 b1 b6 c1 62 84 07 86 52 0c ff 0c 69 58 db
ff a5 06 0c 08 5e 77 38
4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29
61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33
d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3
a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18 61 a4 8e a4
69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d ed e7 75 d3
f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6 c1 62 84 07
86 52 0c ff 0c 69 58 db ff a5 06 0c 08 5e 77 38
Concatenating the parameters AlgorithmID through SuppPubInfo results in a FixedInfo value of (in hex):
00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41
6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00
Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value results in the KDF round 1 hash input of:
00 00 00 01 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39
3b 94 34 29 61 02 40 f4 19 fc 09 2e bc 06 eb a2
c8 27 17 33 d2 7d ea 64 c8 b6 4d 66 de c1 db ce
6d de a1 b3 a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18
61 a4 8e a4 69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d
ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6
c1 62 84 07 86 52 0c ff 0c 69 58 db ff a5 06 0c
08 5e 77 38 00 00 00 07 41 32 35 36 47 43 4d 00
00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00
00 01 00
The resulting derived key, which is the full 256-bits of the round 1 hash output is:
3e 22 44 01 ab cf 8b 1a 93 63 bd 2b 6c 8e 85 c4
e0 c7 b9 8c ad 3b 51 aa 3f 04 a4 9d 0c 29 da 0c
Alice then generates a random 96-bit Initialization Vector (IV) for A256GCM. In hexadecimal format:
3b c5 10 62 97 3c 45 8d 5a 6f 2d 8d
Alice uses the derived key and the IV to encrypt and authenticate the following plaintext JWT Claims Set [RFC7519], with the octets of the encoded JWE Protected Header as the Additional Authenticated Data.
{"msg":"Hello Mike","aud":"Bob","iss":"Alice"}
In hexadecimal notation, the UTF-8 bytes of this plaintext are:
7b 22 6d 73 67 22 3a 22 48 65 6c 6c 6f 20 4d 69
6b 65 22 2c 22 61 75 64 22 3a 22 42 6f 62 22 2c
22 69 73 73 22 3a 22 41 6c 69 63 65 22 7d
The resulting Authentication Tag value is:
4b 39 e8 a7 70 ec eb e3 46 f4 af 77 af 22 4f 42
The JWE Ciphertext is:
b5 bd c4 83 44 54 be 02 04 f6 b5 d5 cd 9c 0d f6
95 57 ab d9 4b ba d4 4f f4 70 0e 57 55 a2 c0 fc
21 ca 63 56 38 93 7b fb 06 3e 60 f4 a4 cb
Alice assembles the complete message in JWE Compact Serialization format and sends it to Bob (with line breaks added for display purposes only):
eyJ0eXAiOiJKV1QiLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J
2IjoiWDQ0OCIsIngiOiI2RFJ4U2VtYUdWeDFpVkVQUnlPQW
NUS1MyekpzaTBvWjliUi1JaFpVSnRlenhqU1hyb1ZvRFRmL
VJWWUJqU1hkd2tMT0lHS1NJNzQifSwiYXB2IjoiUW05aSIs
ImFwdSI6IlFXeHBZMlUiLCJraWQiOiJib2Itc3RhdGljIiw
iZW5jIjoiQTI1NkdDTSIsImFsZyI6IkVDREgtMVBVIn0..O
8UQYpc8RY1aby2N.tb3Eg0RUvgIE9rXVzZwN9pVXq9lLutR
P9HAOV1WiwPwhymNWOJN7-wY-YPSkyw.Sznop3Ds6-NG9K9
3ryJPQg
The message is 383 octets in size.
Bob receives the message from Alice and decrypts it, using Alice's (known) static public key to authenticate that the message did indeed come from Alice. Bob wishes to establish an interactive secure channel with Alice, so replies to her message using the ephemeral key from her initial message as Alice's public key.
Bob generates a fresh ephemeral key-pair of his own. In this example, Bob's ephemeral key-pair (in JWK format) is as follows, including the private key parts (with linebreaks added for display purposes only):
{"kty":"OKP",
"kid":"bob-ephemeral",
"crv":"X448",
"x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhByXl
jx0bNgpAvmf84",
"d":"bNy3py2jvaYOnnzkxV3nOYazDEWTeEOEtTGK7eH-Cjp_m4uCOS-AYqmcUDJCyG
uFj340p3ld0NA"}
Bob generates the following JWE Protected Header for his reply to Alice (with line breaks and whitespace added for display only):
{"typ":"JWT",
"epk":{
"kty":"OKP",
"crv":"X448",
"x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhBy
Xljx0bNgpAvmf84"},
"apv":"QWxpY2U",
"apu":"Qm9i",
"kid":"alice-ephemeral",
"enc":"A256GCM",
"alg":"ECDH-1PU"}
After removing all whitespace, the octets of ASCII(BASE64URL(UTF8(JWE Protected Header))) are as follows (in hexadecimal notation):
65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69
4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35
49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32
49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69
4f 69 4a 66 59 54 52 73 52 7a 42 46 56 6b 38 32
4d 6e 42 35 56 6e 6c 31 52 32 70 44 53 58 70 49
57 55 6c 4a 4e 33 5a 71 52 55 4a 78 5a 6a 41 79
51 32 4e 4f 54 55 4e 49 56 57 70 58 64 6c 4a 4e
53 32 4a 72 57 6b 49 74 57 46 45 77 64 58 70 6f
51 6e 6c 59 62 47 70 34 4d 47 4a 4f 5a 33 42 42
64 6d 31 6d 4f 44 51 69 66 53 77 69 59 58 42 32
49 6a 6f 69 55 56 64 34 63 46 6b 79 56 53 49 73
49 6d 46 77 64 53 49 36 49 6c 46 74 4f 57 6b 69
4c 43 4a 72 61 57 51 69 4f 69 4a 68 62 47 6c 6a
5a 53 31 6c 63 47 68 6c 62 57 56 79 59 57 77 69
4c 43 4a 6c 62 6d 4d 69 4f 69 4a 42 4d 6a 55 32
52 30 4e 4e 49 69 77 69 59 57 78 6e 49 6a 6f 69
52 55 4e 45 53 43 30 78 55 46 55 69 66 51 3d 3d
The resulting KDF parameter values are:
66 83 28 4e 27 bf 2c e9 02 e1 e1 5d 51 de 25 d7
86 21 c7 ee 68 21 0e 55 3f c9 3e 9f cd c3 7f f1
92 b9 c5 35 c2 a2 bc ee bd 03 48 79 82 f9 fb f9
5b d2 c6 88 c8 5c 05 71
4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29
61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33
d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3
a5 d3 12 c7 9a 0c e1 47
66 83 28 4e 27 bf 2c e9 02 e1 e1 5d 51 de 25 d7
86 21 c7 ee 68 21 0e 55 3f c9 3e 9f cd c3 7f f1
92 b9 c5 35 c2 a2 bc ee bd 03 48 79 82 f9 fb f9
5b d2 c6 88 c8 5c 05 71 4c b2 b9 11 cd 1c 0a 69
d2 89 4f 39 3b 94 34 29 61 02 40 f4 19 fc 09 2e
bc 06 eb a2 c8 27 17 33 d2 7d ea 64 c8 b6 4d 66
de c1 db ce 6d de a1 b3 a5 d3 12 c7 9a 0c e1 47
Concatenating the parameters AlgorithmID through SuppPubInfo results in a FixedInfo value of (in hex):
00 00 00 07 41 32 35 36 47 43 4d 00 00 00 03 42
6f 62 00 00 00 05 41 6c 69 63 65 00 00 01 00
Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo value results in the KDF round 1 hash input of:
00 00 00 01 66 83 28 4e 27 bf 2c e9 02 e1 e1 5d
51 de 25 d7 86 21 c7 ee 68 21 0e 55 3f c9 3e 9f
cd c3 7f f1 92 b9 c5 35 c2 a2 bc ee bd 03 48 79
82 f9 fb f9 5b d2 c6 88 c8 5c 05 71 4c b2 b9 11
cd 1c 0a 69 d2 89 4f 39 3b 94 34 29 61 02 40 f4
19 fc 09 2e bc 06 eb a2 c8 27 17 33 d2 7d ea 64
c8 b6 4d 66 de c1 db ce 6d de a1 b3 a5 d3 12 c7
9a 0c e1 47 00 00 00 07 41 32 35 36 47 43 4d 00
00 00 03 42 6f 62 00 00 00 05 41 6c 69 63 65 00
00 01 00
The resulting derived key, which is the full 256-bits of the round 1 hash output is:
7c 22 e5 61 29 89 74 7f 4e d3 b1 94 30 e1 7d 3c
98 14 5c 77 15 5c 71 6a 9d 5d f8 5b ea dd 79 02
Bob then generates a random 96-bit IV for A256GCM. In hexadecimal format:
cd 9f b1 e1 48 cc d8 44 2e 5a a7 49
Bob uses the derived key and the IV to encrypt and authenticate the following plaintext JWT Claims Set, with the octets of the encoded JWE Protected Header as the Additional Authenticated Data.
{"msg":"Hello Joe","aud":"Alice","iss":"Bob"}
In hexadecimal notation, the UTF-8 bytes of this plaintext are:
7b 22 6d 73 67 22 3a 22 48 65 6c 6c 6f 20 4a 6f
65 22 2c 22 61 75 64 22 3a 22 41 6c 69 63 65 22
2c 22 69 73 73 22 3a 22 42 6f 62 22 7d
The resulting Authentication Tag value is:
89 4c a4 f1 a7 7a d0 7b f0 d4 7c da 65 8b d3 95
The JWE Ciphertext is:
02 0d 16 b0 17 d4 8e 04 d2 f4 04 17 09 17 6a 6c
15 57 39 57 c8 ad 16 0c b4 b8 f1 c1 50 18 7d a1
ef cc b2 d1 da 6b 92 b0 32 bb a1 8b 64
Bob assembles the complete message in JWE Compact Serialization format and sends it to Alice (with line breaks added for display purposes only):
eyJ0eXAiOiJKV1QiLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J
2IjoiWDQ0OCIsIngiOiJfYTRsRzBFVk82MnB5Vnl1R2pDSX
pIWUlJN3ZqRUJxZjAyQ2NOTUNIVWpXdlJNS2JrWkItWFEwd
XpoQnlYbGp4MGJOZ3BBdm1mODQifSwiYXB2IjoiUVd4cFky
VSIsImFwdSI6IlFtOWkiLCJraWQiOiJhbGljZS1lcGhlbWV
yYWwiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiRUNESC0xUF
UifQ..zZ-x4UjM2EQuWqdJ.Ag0WsBfUjgTS9AQXCRdqbBVX
OVfIrRYMtLjxwVAYfaHvzLLR2muSsDK7oYtk.iUyk8ad60H
vw1HzaZYvTlQ