idnits 2.17.1 draft-madden-jose-ecdh-1pu-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (May 10, 2019) is 1811 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7748 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Madden 3 Internet-Draft ForgeRock 4 Intended status: Standards Track May 10, 2019 5 Expires: November 11, 2019 7 Public Key Authenticated Encryption for JOSE: ECDH-1PU 8 draft-madden-jose-ecdh-1pu-01 10 Abstract 12 This document describes the ECDH-1PU public key authenticated 13 encryption algorithm for JWE. The algorithm is similar to the 14 existing ECDH-ES encryption algorithm, but adds an additional ECDH 15 key agreement between static keys of the sender and recipient. This 16 additional step allows the recipient to be assured of sender 17 authenticity without requiring a nested signed-then-encrypted message 18 structure. The mode is also a useful building block for constructing 19 interactive handshake protocols on top of JOSE. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on November 11, 2019. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Terminology . . . . . . . . . . . . . . . . 3 57 2. Key Agreement with Elliptic Curve Diffie-Hellman One-Pass 58 Unified Model (ECDH-1PU) . . . . . . . . . . . . . . . . . . 3 59 2.1. Header Parameters used for ECDH Key Agreement . . . . . . 4 60 2.1.1. "skid" Header Parameter . . . . . . . . . . . . . . . 5 61 2.2. Key Derivation for ECDH-1PU Key Agreement . . . . . . . . 5 62 3. Two-way interactive handshake . . . . . . . . . . . . . . . . 6 63 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 7 64 4.1. JSON Web Signature and Encryption Algorithms Registration 7 65 4.1.1. ECDH-1PU . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. JSON Web Signature and Encryption Header Parameters 67 Registration . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.1. skid . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 72 6.2. Informative References . . . . . . . . . . . . . . . . . 10 73 Appendix A. Example ECDH-1PU Key Agreement Computation with 74 A256GCM . . . . . . . . . . . . . . . . . . . . . . 10 75 Appendix B. Example Interactive Handshake . . . . . . . . . . . 13 76 B.1. Initial message from Alice to Bob . . . . . . . . . . . . 14 77 B.2. Response message from Bob to Alice . . . . . . . . . . . 18 78 Appendix C. Document History . . . . . . . . . . . . . . . . . . 21 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 JSON Object Signing and Encryption (JOSE) defines a number of 84 encryption (JWE) [RFC7516] and digital signature (JWS) [RFC7515] 85 algorithms. When symmetric cryptography is used, JWE provides 86 authenticated encryption that ensures both confidentiality and sender 87 authentication. However, for public key cryptography the existing 88 JWE encryption algorithms provide only confidentiality and some level 89 of ciphertext integrity. When sender authentication is required, 90 users must resort to nested signed-then-encrypted structures, which 91 increases the overhead and size of resulting messages. This document 92 describes an alternative encryption algorithm called ECDH-1PU that 93 provides public key authenticated encryption, allowing the benefits 94 of authenticated encryption to be enjoyed for public key JWE as it 95 currently is for symmetric cryptography. 97 ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve 98 Diffie-Hellman key agreement described in [NIST.800-56A]. 100 The advantages of public key authenticated encryption with ECDH-1PU 101 compared to using nested signed-then-encrypted documents include the 102 following: 104 o The resulting message size is more compact as an additional layer 105 of headers and base64url-encoding is avoided. A 500-byte payload 106 when encrypted and authenticated with ECDH-1PU (with P-256 keys 107 and "A256GCM" Content Encryption Method) results in a 1087-byte 108 JWE in Compact Encoding. An equivalent nested signed-then- 109 encrypted JOSE message using the same keys and encryption method 110 is 1489 bytes (37% larger). 112 o The same primitives are used for both confidentiality and 113 authenticity, providing savings in code size for constrained 114 environments. 116 o The generic composition of signatures and public key encryption 117 involves a number of subtle details that are essential to security 118 [PKAE]. Providing a dedicated algorithm for public key 119 authenticated encryption reduces complexity for users of JOSE 120 libraries. 122 o ECDH-1PU provides only authenticity and not the stronger security 123 properties of non-repudiation or third-party verifiability. This 124 can be an advantage in applications where privacy, anonymity, or 125 plausible deniability are goals. 127 1.1. Requirements Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 131 "OPTIONAL" in this document are to be interpreted as described in BCP 132 14 [RFC8174] when, and only when, they appear in all capitals, as 133 shown here. 135 2. Key Agreement with Elliptic Curve Diffie-Hellman One-Pass Unified 136 Model (ECDH-1PU) 138 This section defines the specifics of key agreement with Elliptic 139 Curve Diffie-Hellman One-Pass Unified Model, in combination with the 140 one-step KDF, as defined in Section 5.8.2.1 of [NIST.800-56A] using 141 the Concatenation Format of Section 5.8.2.1.1. This is identical to 142 the ConcatKDF function used by the existing JWE ECDH-ES algorithm 143 defined in Section 4.6 of [RFC7518]. As for ECDH-ES, the key 144 agreement result can be used in one of two ways: 146 1. directly as the Content Encryption Key (CEK) for the "enc" 147 algorithm, in the Direct Key Agreement mode, or 149 2. as a symmetric key used to wrap the CEK with the "A128KW", 150 "A192KW", or "A256KW" algorithms, in the Key Agreement with Key 151 Wrapping mode. 153 A new ephemeral public key value MUST be generated for each key 154 agreement operation. 156 In Direct Key Agreement mode, the output of the KDF MUST be a key of 157 the same length as that used by the "enc" algorithm. In this case, 158 the empty octet sequence is used as the JWE Encrypted Key value. The 159 "alg" (algorithm) Header Parameter value "ECDH-1PU" is used in Direct 160 Key Agreement mode. 162 In Key Agreement with Key Wrapping mode, the output of the KDF MUST 163 be a key of the length needed for the specified key wrapping 164 algorithm. In this case, the JWE Encrypted Key is the CEK wrapped 165 with the agreed-upon key. 167 The following "alg" (algorithm) Header Parameter values are used to 168 indicate the JWE Encrypted Key is the result of encrypting the CEK 169 using the result of the key agreement algorithm as the key encryption 170 key for the corresponding key wrapping algorithm: 172 +-----------------+-------------------------------------------------+ 173 | "alg" Param | Key Management Algorithm | 174 | Value | | 175 +-----------------+-------------------------------------------------+ 176 | ECDH-1PU+A128KW | ECDH-1PU using one-pass KDF and CEK wrapped | 177 | | with "A128KW" | 178 | ECDH-1PU+A192KW | ECDH-1PU using one-pass KDF and CEK wrapped | 179 | | with "A192KW" | 180 | ECDH-1PU+A256KW | ECDH-1PU using one-pass KDF and CEK wrapped | 181 | | with "A256KW" | 182 +-----------------+-------------------------------------------------+ 184 2.1. Header Parameters used for ECDH Key Agreement 186 The "epk" (ephemeral public key), "apu" (Agreement PartyUInfo), and 187 "apv" (Agreement PartyVInfo) header parameters are used in ECDH-1PU 188 exactly as defined in Section 4.6.1 of [RFC7518]. 190 When no other values are supplied, it is RECOMMENDED that the 191 producer software initializes the "apu" header to the base64url- 192 encoding of the SHA-256 hash of the concatenation of the sender's 193 static public key and the ephemeral public key, and the "apv" header 194 to the base64url-encoding of the SHA-256 hash of the recipient's 195 static public key. This ensures that all keys involved in the key 196 agreement are cryptographically bound to the derived keys. 198 2.1.1. "skid" Header Parameter 200 A new Header Parameter "skid" (Sender Key ID) is registered as a hint 201 as to which of the sender's keys was used to authenticate the JWE. 202 The structure of the "skid" value is unspecified. Its value MUST be 203 a case-sensitive string. Use of this Header Parameter is OPTIONAL. 204 When used with a JWK, the "skid" value is used to match a JWK "kid" 205 parameter value. 207 2.2. Key Derivation for ECDH-1PU Key Agreement 209 The key derivation process derives the agreed-upon key from the 210 shared secret Z established through the ECDH algorithm, per 211 Section 6.2.1.2 of [NIST.800-56A]. For the NIST prime order curves 212 "P-256", "P-384", and "P-521", the ECC CDH primitive for cofactor 213 Diffie-Hellman defined in Section 5.7.1.2 of [NIST.800-56A] is used 214 (taking note that the cofactor for all these curves is 1). For 215 curves "X25519" and "X448" the appropriate ECDH primitive from 216 Section 5 of [RFC7748] is used. 218 Key derivation is performed using the one-step KDF, as defined in 219 Section 5.8.1 and Section 5.8.2.1 of [NIST.800-56A] using the 220 Concatenation Format of Section 5.8.2.1.1, where the Auxilary 221 Function H is SHA-256. The KDF parameters are set as follows: 223 Z This is set to the representation of the shared secret Z as an 224 octet sequence. As per Section 6.2.1.2 of [NIST.800-56A] Z is the 225 concatenation of Ze and Zs, where Ze is the shared secret derived 226 from applying the ECDH primitive to the sender's ephemeral private 227 key and the recipient's static public key. Zs is the shared 228 secret derived from applying the ECDH primitive to the sender's 229 static private key and the recipient's static public key. 231 keydatalen This is set to the number of bits in the desired output 232 key. For "ECDH-1PU", this is the length of the key used by the 233 "enc" algorithm. For "ECDH-1PU+A128KW", "ECDH-1PU+A192KW", and 234 "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively. 236 AlgorithmID The AlgorithmID values is of the form Datalen || Data, 237 where Data is a variable-length string of zero or more octets, and 238 Datalen is a fixed-length, big-endian 32-bit counter that 239 indicates the length (in octets) of Data. In the Direct Key 240 Agreement case, Data is set to the octets of the ASCII 241 representation of the "enc" Header Parameter value. In the Key 242 Agreement with Key Wrapping case, Data is set to the octets of the 243 ASCII representation of the "alg" (algorithm) Header Parameter 244 value. 246 PartyUInfo The PartyUInfo value is of the form Datalen || Data, 247 where Data is a variable-length string of zero or more octets, and 248 Datalen is a fixed-length, big-endian 32-bit counter that 249 indicates the length (in octets) of Data. If an "apu" (agreement 250 PartyUInfo) Header Parameter is present, Data is set to the result 251 of base64url decoding the "apu" value and Datalen is set to the 252 number of octets in Data. Otherwise, Datalen is set to 0 and Data 253 is set to the empty octet sequence. 255 PartyVInfo The PartyVInfo value is of the form Datalen || Data, 256 where Data is a variable-length string of zero or more octets, and 257 Datalen is a fixed-length, big-endian 32-bit counter that 258 indicates the length (in octets) of Data. If an "apv" (agreement 259 PartyVInfo) Header Parameter is present, Data is set to the result 260 of base64url decoding the "apv" value and Datalen is set to the 261 number of octets in Data. Otherwise, Datalen is set to 0 and Data 262 is set to the empty octet sequence. 264 SuppPubInfo This is set to the keydatalen represented as a 32-bit 265 big-endian integer. 267 SuppPrivInfo This is set to the empty octet sequence. 269 Applications need to specifiy how the "apu" and "apv" Header 270 Parameters are used for that application. The "apu" and "apv" values 271 MUST be distinct, when used. Applications wishing to conform to 272 [NIST.800-56A] need to provide values that meet the requirements of 273 that doucument, e.g., by using values that identify the producer and 274 consumer. 276 See Appendix A for an example key agreement computation using this 277 method. 279 3. Two-way interactive handshake 281 A party that has received a JWE encrypted with ECDH-1PU MAY reply to 282 that message by creating a new JWE using ECDH-1PU, but using the 283 ephemeral public key ("epk") from the first message as if it was the 284 originating party's static public key. In this case, key agreement 285 proceeds exactly as for Section 2, but with the originator's 286 ephemeral public key used as the recipient (Party V) static public 287 key. The "alg" (algorithm) Header Parameter in the response MUST be 288 identical to the "alg" Header Parameter of the original message. The 289 "enc" (encryption method) Header Parameter in the response MUST also 290 be identical to the "enc" Header Parameter of the original message. 292 The value of the "apu" (Agreement PartyUInfo) Header Parameter value 293 from the original message SHOULD be reflected as the "apv" (Agreement 294 PartyVInfo) Header Parameter value in the new message. Applications 295 need to specify how the new "apu" Header Parameter should be 296 constructed. 298 If a "kid" claim was included in the ephemeral public key of the 299 original message, then a "kid" Header Parameter with the same value 300 MUST be included in the reply JWE. 302 See Appendix B for an example handshake using this method. 304 After the initial message and a reply have been exchanged, the two 305 parties may communicate using the derived key from the second message 306 as the encryption key for any number of additional messages. 307 Applications MUST specify the algorithm to be used. The JWE 308 algorithm and encryption method used MUST use the same size key as 309 the derived key. For example, if the derived key is 256-bits, then 310 appropriate algorithms include alg=dir and enc=A256GCM, or alg=A256KW 311 with any JWE content encryption method. 313 If Direct encryption is used, the "enc" (encryption method) of all 314 subsequent messages MUST be identical to the "enc" Header Parameter 315 of the handshake messages. If the same derived key is to be used for 316 messages in both directions between the two parties, the application 317 MUST specify how unique nonces/IVs are to be generated by each party 318 to avoid collisions. It is RECOMMENDED that either a Key Wrap 319 algorithm is used, or else the derived key is used as input to a key 320 derivation function to derive separate keys for each direction. 322 4. IANA considerations 324 This section registers identifiers under the IANA JSON Web Signature 325 and Encryption Algorithms Registry established by [RFC7518] and the 326 IANA JSON Web Signature and Encryption Header Parameters registry 327 established by [RFC7515]. 329 4.1. JSON Web Signature and Encryption Algorithms Registration 331 This section registers JWE algorithms as per the registry established 332 in [RFC7518]. 334 4.1.1. ECDH-1PU 336 Algorithm Name: "ECDH-1PU" 337 Algorithm Description: ECDH One-Pass Unified Model using one-pass 338 KDF 339 Algorithm Usage Location(s): "alg" 340 JOSE Implementation Requirements: Optional 341 Change Controller: IESG 342 Specification Document(s): Section 2 343 Algorithm Analysis Document(s): [NIST.800-56A] (Section 7.3), 344 [PKAE] 346 4.2. JSON Web Signature and Encryption Header Parameters Registration 348 This section registers new Header Parameters as per the registry 349 established in [RFC7515]. 351 4.2.1. skid 353 Header Parameter Name: "skid" 354 Header Parameter Description: Sender Key ID 355 Header Parameter Usage Location(s): JWE 356 Change Controller: IESG 357 Specification Document(s): Section 2.1.1 359 5. Security Considerations 361 The security considerations of [RFC7516] and [RFC7518] relevant to 362 ECDH-ES also apply to this specification. 364 The security considerations of [NIST.800-56A] apply here. 366 When performing an ECDH key agreement between a static private key 367 and any untrusted public key, care should be taken to ensure that the 368 public key is a valid point on the same curve as the private key. 369 Failure to do so may result in compromise of the static private key. 370 For the NIST curves P-256, P-384, and P-521, appropriate validation 371 routines are given in Section 5.6.2.3.3 of [NIST.800-56A]. For the 372 curves used by X25519 and X448, consult the security considerations 373 of [RFC7748]. 375 The ECDH-1PU algorithm is vulnerable to Key Compromise Impersonation 376 (KCI) attacks. If the long-term static private key of a party is 377 compromised, then the attacker can not only impersonate that party to 378 other parties, but also impersonate any other party when 379 communicating with the compromised party. The second and any 380 subsequent messages in the two-way interactive handshake described in 381 Section 3 are not vulnerable to KCI. If resistance to KCI is desired 382 in a single message, then it is RECOMMENDED to use a nested JWS 383 signature over the content. 385 When Key Agreement with Key Wrapping is used, with the same Content 386 Encryption Key (CEK) reused for multiple recipients, any of those 387 recipients can produce a new message that appears to come from the 388 original sender. The new message will be indistinguishable from a 389 genuine message from the original sender to any of the other 390 participants. The sender SHOULD use a unique CEK for each recipient 391 of a message. 393 The security properties of the one-pass unified model are given in 394 Section 7.3 of [NIST.800-56A]. The ECDH-1PU scheme is also related 395 (but not identical) to the "K" one-way handshake pattern of the Noise 396 Protocol Framework. The two-way interactive handshake described in 397 Section 3 is also related to the "KK" two-way interactive handshake 398 pattern. The security properties of these handshake patterns are 399 given in Section 7.7 of [Noise], although it should be stressed that 400 many details differ between Noise and the current specification. 402 6. References 404 6.1. Normative References 406 [NIST.800-56A] 407 Barker, E., Chen, L., Roginsky, A., Vassilev, A., and R. 408 Davis, "Recommendation for Pair-Wise Key Establishment 409 Using Discrete Logarithm Cryptography Revision 3.", NIST 410 Special Publication 800-56A, April 2018. 412 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 413 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 414 2015, . 416 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 417 RFC 7516, DOI 10.17487/RFC7516, May 2015, 418 . 420 [RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518, 421 DOI 10.17487/RFC7518, May 2015, 422 . 424 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 425 for Security", RFC 7748, DOI 10.17487/RFC7748, January 426 2016, . 428 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 429 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 430 May 2017, . 432 6.2. Informative References 434 [Noise] Perrin, T., "The Noise Protocol Framework, Revision 34", 435 July 2018. 437 [PKAE] An, J., "Authenticated Encryption in the Public-Key 438 Setting: Security Notions and Analyses", IACR ePrint 439 2001/079, 2001. 441 [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token 442 (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, 443 . 445 [RFC8037] Liusvaara, I., "CFRG Elliptic Curve Diffie-Hellman (ECDH) 446 and Signatures in JSON Object Signing and Encryption 447 (JOSE)", RFC 8037, DOI 10.17487/RFC8037, January 2017, 448 . 450 Appendix A. Example ECDH-1PU Key Agreement Computation with A256GCM 452 This example uses ECDH-1PU in Direct Key Agreement mode ("alg" value 453 "ECDH-1PU") to produce an agreed-upon key for AES GCM with a 256-bit 454 key ("enc" value "A256GCM"). The example re-uses the keys and 455 parameters of the example computation in Appendix C of [RFC7518], 456 with the addition of an extra static key-pair for Alice. 458 When used in this way, ECDH-1PU has similar security properties to 459 the "K" one-way handshake pattern of [Noise], although it is quite 460 different in details. 462 In this example, a producer Alice is encrypting content to a consumer 463 Bob. Alice's static key-pair (in JWK format) used for the key 464 agreement in this example (including the private part) is: 466 {"kty":"EC", 467 "crv":"P-256", 468 "x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis", 469 "y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE", 470 "d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"} 472 Bob's static key-pair (in JWK format) is: 474 {"kty":"EC", 475 "crv":"P-256", 476 "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ", 477 "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck", 478 "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"} 480 The producer (Alice) generates an ephemeral key for the key agreement 481 computation. Alice's ephemeral key (in JWK format) is: 483 {"kty":"EC", 484 "crv":"P-256", 485 "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", 486 "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps", 487 "d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"} 489 Header Parameter values used in this example are as follows. The 490 "apu" (agreement PartyUInfo) Header Parameter value is the base64url 491 encoding of the UTF-8 string "Alice" and the "apv" (agreement 492 PartyVInfo) Header Parameter value is the base64url encoding of the 493 UTF-8 string "Bob". The "epk" (ephemeral public key) Header 494 Parameter is used to communicate the producer's (Alice's) ephemeral 495 public key value to the consumer (Bob). 497 {"alg":"ECDH-1PU", 498 "enc":"A256GCM", 499 "apu":"QWxpY2U", 500 "apv":"Qm9i", 501 "epk": 502 {"kty":"EC", 503 "crv":"P-256", 504 "x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0", 505 "y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps" 506 } 507 } 509 The resulting one-pass KDF [NIST.800-56A] parameter values are: 511 Ze This is set to the output of the ECDH key agreement between 512 Alice's ephemeral private key and Bob's static public key. In 513 this example, Ze is the following octet sequence (in hexadecimal 514 notation): 516 9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c 517 fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4 519 Zs This is set to the output of the ECDH key agreement between 520 Alice's static private key and Bob's static public key. In this 521 example, Zs is the following octet sequence (in hexadecimal 522 notation): 524 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d 525 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d 527 Z This is set to the concatenation of Ze followed by Zs. In this 528 example, Z is the following octet sequence (in hexadecimal 529 notation): 531 9e 56 d9 1d 81 71 35 d3 72 83 42 83 bf 84 26 9c 532 fb 31 6e a3 da 80 6a 48 f6 da a7 79 8c fe 90 c4 533 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 68 8b 3e 7d 534 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 41 ef d5 0d 536 keydatalen This value is 256 - the number of bits in the desired 537 output key (because "A256GCM" uses a 256-bit key). 538 AlgorithmID This is set to the octets representing the 32-bit big- 539 endian value 7 - 00 00 00 07 in hexadecimal notation - the number 540 of octets in the AlgorithmID content "A256GCM", followed by the 541 octets representing the ASCII string "A256GCM" - 41 32 35 36 47 43 542 4d (in hex). The complete value is therefore: 00 00 00 07 41 32 543 35 36 47 43 4d 544 PartyUInfo This is set to the octets representing the 32-bit big- 545 endian value 5, followed by the octets representing the UTF-8 546 string "Alice". In hexadecimal notation: 00 00 00 05 41 6c 69 63 547 65 548 PartyVInfo This is set to the octets representing the 32-bit big- 549 endian value 3, followed by the octets representing the UTF-8 550 string "Bob". In hexadecimal notation: 00 00 00 03 42 6f 62 551 SuppPubInfo This is set to the octets representing the 32-bit big- 552 endian value 256 - the keydatalen value. In hexadecimal notation: 553 00 00 01 00 554 SuppPrivInfo This is set to the empty octet sequence. 556 Concatenating the parameters AlgorithmID through SuppPrivInfo results 557 in a FixedInfo value in Concatenation Format (as per 558 Section 5.8.2.1.1 of [NIST.800-56A]) of (in hexidecimal notation): 560 00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41 561 6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00 563 Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo 564 value results in a one-pass KDF round 1 hash input of (hexadecimal): 566 00 00 00 01 9e 56 d9 1d 81 71 35 d3 72 83 42 83 567 bf 84 26 9c fb 31 6e a3 da 80 6a 48 f6 da a7 79 568 8c fe 90 c4 e3 ca 34 74 38 4c 9f 62 b3 0b fd 4c 569 68 8b 3e 7d 41 10 a1 b4 ba dc 3c c5 4e f7 b8 12 570 41 ef d5 0d 00 00 00 07 41 32 35 36 47 43 4d 00 571 00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00 572 00 01 00 574 The resulting derived key, which is the full 256 bits of the round 1 575 hash output is: 577 6c af 13 72 3d 14 85 0a d4 b4 2c d6 dd e9 35 bf 578 fd 2f ff 00 a9 ba 70 de 05 c2 03 a5 e1 72 2c a7 580 The base64url-encoded representation of this derived key is: 582 bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc 584 Appendix B. Example Interactive Handshake 586 This example use ECDH-1PU in Direct Key Agreement mode using the X448 587 curve from [RFC8037] to perform a two-way interactive handshake. 588 When used in this way, ECDH-1PU has similar security properties to 589 the "KK" interactive handshake pattern of [Noise]. Messages are 590 encrypted using the "A256GCM" encryption method ("enc" Header 591 Parameter value). 593 In this example, a producer Alice is encrypting content to a consumer 594 Bob. Alice's static key-pair (in JWK format) including the private 595 key part is (with linebreaks added for display purposes only): 597 {"kty":"OKP", 598 "kid":"alice-static", 599 "crv": "X448", 600 "x":"qaggoGo7qFwBrBtxv4hwI09UaiQmCrF1KdHvaXrzjzzInqDD0Cfx9GlGFi2367 601 RATs-hBoB2IHw", 602 "d":"hJW9knOYfyCIkZnW922U81uDNNfAwcVeNcpbaQIKyh0iW5LSpDLSmBdPSyvOh7 603 J4u9hArU2uoX0"} 605 Bob's static key-pair (in JWK format) including the private key part 606 is (with linebreaks added for display purposes only): 608 {"kty":"OKP", 609 "kid":"bob-static", 610 "crv":"X448", 611 "x":"4jvO2Ef15DErhV5_5OzoaZDQ2tVb_jHB09eNruOkCTETatzOZ2EGgJCkXNElWR 612 sLnbns3TtYYSY", 613 "d":"HGKc9R7_Zso3BCnrhzA9GzOzHKHOkMYvb_n54aJ1qkO1qYYTEUS0OQmBZTq1NK 614 R5_kmiX5e5r-I"} 616 B.1. Initial message from Alice to Bob 618 Alice generates an ephemeral key-pair for her handshake with Bob. 619 Alice's ephemeral key-pair in JWK format is (with linebreaks added 620 for display purposes only): 622 {"kty":"OKP", 623 "kid":"alice-ephemeral", 624 "crv":"X448", 625 "x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYBjS 626 XdwkLOIGKSI74", 627 "d":"8epzr7H0N7ZIIOZeNckLL3iAHfSmIDeb-cMSgI8PJzyQfjZB0tHoGFtkQG7cAK 628 xP0Fi6Bbfbe7I"} 630 The following JWE Protected Header is used for the message (with line 631 breaks and whitespace added for display purposes): 633 {"typ":"JWT", 634 "epk":{ 635 "kty":"OKP", 636 "crv":"X448", 637 "x":"6DRxSemaGVx1iVEPRyOAcTKS2zJsi0oZ9bR-IhZUJtezxjSXroVoDTf-RVYB 638 jSXdwkLOIGKSI74"}, 639 "apv":"Qm9i", 640 "apu":"QWxpY2U", 641 "kid":"bob-static", 642 "enc":"A256GCM", 643 "alg":"ECDH-1PU"} 645 After removing all whitespace, the octets of ASCII(BASE64URL(UTF8(JWE 646 Protected Header))) are as follows (in hexadecimal notation): 648 65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69 649 4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35 650 49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32 651 49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69 652 4f 69 49 32 52 46 4a 34 55 32 56 74 59 55 64 57 653 65 44 46 70 56 6b 56 51 55 6e 6c 50 51 57 4e 55 654 53 31 4d 79 65 6b 70 7a 61 54 42 76 57 6a 6c 69 655 55 69 31 4a 61 46 70 56 53 6e 52 6c 65 6e 68 71 656 55 31 68 79 62 31 5a 76 52 46 52 6d 4c 56 4a 57 657 57 55 4a 71 55 31 68 6b 64 32 74 4d 54 30 6c 48 658 53 31 4e 4a 4e 7a 51 69 66 53 77 69 59 58 42 32 659 49 6a 6f 69 55 57 30 35 61 53 49 73 49 6d 46 77 660 64 53 49 36 49 6c 46 58 65 48 42 5a 4d 6c 55 69 661 4c 43 4a 72 61 57 51 69 4f 69 4a 69 62 32 49 74 662 63 33 52 68 64 47 6c 6a 49 69 77 69 5a 57 35 6a 663 49 6a 6f 69 51 54 49 31 4e 6b 64 44 54 53 49 73 664 49 6d 46 73 5a 79 49 36 49 6b 56 44 52 45 67 74 665 4d 56 42 56 49 6e 30 667 The resulting one-pass KDF [NIST.800-56A] parameter values are: 669 Ze This is set to the output of the X448 key agreement between 670 Alice's ephemeral private key and Bob's static public key. In 671 this example, Ze is the following octet sequence (in hexadecimal 672 notation): 674 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29 675 61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33 676 d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3 677 a5 d3 12 c7 9a 0c e1 47 679 Zs This is set to the output of the X448 key agreement between 680 Alice's static private key and Bob's static public key. In this 681 example, Zs is the following octet sequence (in hexadecimal 682 notation): 684 d8 8e aa 18 61 a4 8e a4 69 7b e0 99 c6 bc 3b 73 685 4f 0e 13 6d ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0 686 e0 39 b1 b6 c1 62 84 07 86 52 0c ff 0c 69 58 db 687 ff a5 06 0c 08 5e 77 38 689 Z This is set to the concatenation of Ze followed by Zs. In this 690 example, Z is the following octet sequence (in hexadecimal 691 notation): 693 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29 694 61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33 695 d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3 696 a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18 61 a4 8e a4 697 69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d ed e7 75 d3 698 f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6 c1 62 84 07 699 86 52 0c ff 0c 69 58 db ff a5 06 0c 08 5e 77 38 701 keydatalen This value is 256, because "A256GCM" uses a 256-bit key. 702 AlgorithmID This is set to the octets representing the 32-bit big- 703 endian value 7 followed by the octets representing the ASCII 704 string "A256GCM". In hexadecimal notation: 00 00 00 07 41 32 35 705 36 47 43 4d 706 PartyUInfo This is set to the octets representing the 32-bit big- 707 endian value 5 followed by the octets representing the UTF-8 708 string "Alice". In hexadecimal notation: 00 00 00 05 41 6c 69 63 709 65 710 PartyVInfo This is set to the octets representing the 32-bit big- 711 endian value 3 followed by the octets representing the UTF-8 712 string "Bob". In hexadecimal notation: 00 00 00 03 42 6f 62 713 SuppPubInfo This is set to the octets representing the 32-bit big 714 endian value 256 - the keydatalen value. In hexadecimal: 00 00 01 715 00 716 SuppPrivInfo This is set to the empty octet sequence. 718 Concatenating the parameters AlgorithmID through SuppPubInfo results 719 in a FixedInfo value of (in hex): 721 00 00 00 07 41 32 35 36 47 43 4d 00 00 00 05 41 722 6c 69 63 65 00 00 00 03 42 6f 62 00 00 01 00 724 Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo 725 value results in the KDF round 1 hash input of: 727 00 00 00 01 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 728 3b 94 34 29 61 02 40 f4 19 fc 09 2e bc 06 eb a2 729 c8 27 17 33 d2 7d ea 64 c8 b6 4d 66 de c1 db ce 730 6d de a1 b3 a5 d3 12 c7 9a 0c e1 47 d8 8e aa 18 731 61 a4 8e a4 69 7b e0 99 c6 bc 3b 73 4f 0e 13 6d 732 ed e7 75 d3 f3 a2 f4 86 b7 47 ba f0 e0 39 b1 b6 733 c1 62 84 07 86 52 0c ff 0c 69 58 db ff a5 06 0c 734 08 5e 77 38 00 00 00 07 41 32 35 36 47 43 4d 00 735 00 00 05 41 6c 69 63 65 00 00 00 03 42 6f 62 00 736 00 01 00 738 The resulting derived key, which is the full 256-bits of the round 1 739 hash output is: 741 3e 22 44 01 ab cf 8b 1a 93 63 bd 2b 6c 8e 85 c4 742 e0 c7 b9 8c ad 3b 51 aa 3f 04 a4 9d 0c 29 da 0c 744 Alice then generates a random 96-bit Initialization Vector (IV) for 745 A256GCM. In hexadecimal format: 747 3b c5 10 62 97 3c 45 8d 5a 6f 2d 8d 749 Alice uses the derived key and the IV to encrypt and authenticate the 750 following plaintext JWT Claims Set [RFC7519], with the octets of the 751 encoded JWE Protected Header as the Additional Authenticated Data. 753 {"msg":"Hello Mike","aud":"Bob","iss":"Alice"} 755 In hexadecimal notation, the UTF-8 bytes of this plaintext are: 757 7b 22 6d 73 67 22 3a 22 48 65 6c 6c 6f 20 4d 69 758 6b 65 22 2c 22 61 75 64 22 3a 22 42 6f 62 22 2c 759 22 69 73 73 22 3a 22 41 6c 69 63 65 22 7d 761 The resulting Authentication Tag value is: 763 4b 39 e8 a7 70 ec eb e3 46 f4 af 77 af 22 4f 42 765 The JWE Ciphertext is: 767 b5 bd c4 83 44 54 be 02 04 f6 b5 d5 cd 9c 0d f6 768 95 57 ab d9 4b ba d4 4f f4 70 0e 57 55 a2 c0 fc 769 21 ca 63 56 38 93 7b fb 06 3e 60 f4 a4 cb 771 Alice assembles the complete message in JWE Compact Serialization 772 format and sends it to Bob (with line breaks added for display 773 purposes only): 775 eyJ0eXAiOiJKV1QiLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J 776 2IjoiWDQ0OCIsIngiOiI2RFJ4U2VtYUdWeDFpVkVQUnlPQW 777 NUS1MyekpzaTBvWjliUi1JaFpVSnRlenhqU1hyb1ZvRFRmL 778 VJWWUJqU1hkd2tMT0lHS1NJNzQifSwiYXB2IjoiUW05aSIs 779 ImFwdSI6IlFXeHBZMlUiLCJraWQiOiJib2Itc3RhdGljIiw 780 iZW5jIjoiQTI1NkdDTSIsImFsZyI6IkVDREgtMVBVIn0..O 781 8UQYpc8RY1aby2N.tb3Eg0RUvgIE9rXVzZwN9pVXq9lLutR 782 P9HAOV1WiwPwhymNWOJN7-wY-YPSkyw.Sznop3Ds6-NG9K9 783 3ryJPQg 785 The message is 383 octets in size. 787 B.2. Response message from Bob to Alice 789 Bob receives the message from Alice and decrypts it, using Alice's 790 (known) static public key to authenticate that the message did indeed 791 come from Alice. Bob wishes to establish an interactive secure 792 channel with Alice, so replies to her message using the ephemeral key 793 from her initial message as Alice's public key. 795 Bob generates a fresh ephemeral key-pair of his own. In this 796 example, Bob's ephemeral key-pair (in JWK format) is as follows, 797 including the private key parts (with linebreaks added for display 798 purposes only): 800 {"kty":"OKP", 801 "kid":"bob-ephemeral", 802 "crv":"X448", 803 "x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhByXl 804 jx0bNgpAvmf84", 805 "d":"bNy3py2jvaYOnnzkxV3nOYazDEWTeEOEtTGK7eH-Cjp_m4uCOS-AYqmcUDJCyG 806 uFj340p3ld0NA"} 808 Bob generates the following JWE Protected Header for his reply to 809 Alice (with line breaks and whitespace added for display only): 811 {"typ":"JWT", 812 "epk":{ 813 "kty":"OKP", 814 "crv":"X448", 815 "x":"_a4lG0EVO62pyVyuGjCIzHYII7vjEBqf02CcNMCHUjWvRMKbkZB-XQ0uzhBy 816 Xljx0bNgpAvmf84"}, 817 "apv":"QWxpY2U", 818 "apu":"Qm9i", 819 "kid":"alice-ephemeral", 820 "enc":"A256GCM", 821 "alg":"ECDH-1PU"} 823 After removing all whitespace, the octets of ASCII(BASE64URL(UTF8(JWE 824 Protected Header))) are as follows (in hexadecimal notation): 826 65 79 4a 30 65 58 41 69 4f 69 4a 4b 56 31 51 69 827 4c 43 4a 6c 63 47 73 69 4f 6e 73 69 61 33 52 35 828 49 6a 6f 69 54 30 74 51 49 69 77 69 59 33 4a 32 829 49 6a 6f 69 57 44 51 30 4f 43 49 73 49 6e 67 69 830 4f 69 4a 66 59 54 52 73 52 7a 42 46 56 6b 38 32 831 4d 6e 42 35 56 6e 6c 31 52 32 70 44 53 58 70 49 832 57 55 6c 4a 4e 33 5a 71 52 55 4a 78 5a 6a 41 79 833 51 32 4e 4f 54 55 4e 49 56 57 70 58 64 6c 4a 4e 834 53 32 4a 72 57 6b 49 74 57 46 45 77 64 58 70 6f 835 51 6e 6c 59 62 47 70 34 4d 47 4a 4f 5a 33 42 42 836 64 6d 31 6d 4f 44 51 69 66 53 77 69 59 58 42 32 837 49 6a 6f 69 55 56 64 34 63 46 6b 79 56 53 49 73 838 49 6d 46 77 64 53 49 36 49 6c 46 74 4f 57 6b 69 839 4c 43 4a 72 61 57 51 69 4f 69 4a 68 62 47 6c 6a 840 5a 53 31 6c 63 47 68 6c 62 57 56 79 59 57 77 69 841 4c 43 4a 6c 62 6d 4d 69 4f 69 4a 42 4d 6a 55 32 842 52 30 4e 4e 49 69 77 69 59 57 78 6e 49 6a 6f 69 843 52 55 4e 45 53 43 30 78 55 46 55 69 66 51 3d 3d 845 The resulting KDF parameter values are: 847 Ze This is set to the output of the X448 key agreement between Bob's 848 ephemeral private key and Alice's ephemeral public key (from the 849 first message). Note that this is an ephemeral-ephemeral key 850 agreement. In hexadecimal notation: 852 66 83 28 4e 27 bf 2c e9 02 e1 e1 5d 51 de 25 d7 853 86 21 c7 ee 68 21 0e 55 3f c9 3e 9f cd c3 7f f1 854 92 b9 c5 35 c2 a2 bc ee bd 03 48 79 82 f9 fb f9 855 5b d2 c6 88 c8 5c 05 71 857 Zs This is set to the output of the X448 key agreement between Bob's 858 static private key and Alice's ephemeral public key from the first 859 message. In hexadecimal notation: 861 4c b2 b9 11 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29 862 61 02 40 f4 19 fc 09 2e bc 06 eb a2 c8 27 17 33 863 d2 7d ea 64 c8 b6 4d 66 de c1 db ce 6d de a1 b3 864 a5 d3 12 c7 9a 0c e1 47 866 Z Z is the concatenation of Ze and Zs: 868 66 83 28 4e 27 bf 2c e9 02 e1 e1 5d 51 de 25 d7 869 86 21 c7 ee 68 21 0e 55 3f c9 3e 9f cd c3 7f f1 870 92 b9 c5 35 c2 a2 bc ee bd 03 48 79 82 f9 fb f9 871 5b d2 c6 88 c8 5c 05 71 4c b2 b9 11 cd 1c 0a 69 872 d2 89 4f 39 3b 94 34 29 61 02 40 f4 19 fc 09 2e 873 bc 06 eb a2 c8 27 17 33 d2 7d ea 64 c8 b6 4d 66 874 de c1 db ce 6d de a1 b3 a5 d3 12 c7 9a 0c e1 47 876 keydatalen This is the value 256. 877 AlgorithmID This is set to the octets representing the 32-bit big- 878 endian value 7 followed by the octets representing the ASCII 879 string "A256GCM". In hexadecimal notation: 00 00 00 07 41 32 35 880 36 47 43 4d 881 PartyUInfo This is set to the octets representing the 32-bit big- 882 endian value 3 followed by the octets representing the UTF-8 883 string "Bob". In hexadecimal notation: 00 00 00 03 42 6f 62 884 PartyVInfo Bob echoes back Alice's PartyUInfo as the new PartyVInfo: 885 00 00 00 05 41 6c 69 63 65 886 SuppPubInfo This is set to the octets representing the 32-bit big 887 endian value 256 - the keydatalen value. In hexadecimal: 00 00 01 888 00 889 SuppPrivInfo This is set to the empty octet sequence. 891 Concatenating the parameters AlgorithmID through SuppPubInfo results 892 in a FixedInfo value of (in hex): 894 00 00 00 07 41 32 35 36 47 43 4d 00 00 00 03 42 895 6f 62 00 00 00 05 41 6c 69 63 65 00 00 01 00 897 Concatenating the round number 1 (00 00 00 01), Z, and the FixedInfo 898 value results in the KDF round 1 hash input of: 900 00 00 00 01 66 83 28 4e 27 bf 2c e9 02 e1 e1 5d 901 51 de 25 d7 86 21 c7 ee 68 21 0e 55 3f c9 3e 9f 902 cd c3 7f f1 92 b9 c5 35 c2 a2 bc ee bd 03 48 79 903 82 f9 fb f9 5b d2 c6 88 c8 5c 05 71 4c b2 b9 11 904 cd 1c 0a 69 d2 89 4f 39 3b 94 34 29 61 02 40 f4 905 19 fc 09 2e bc 06 eb a2 c8 27 17 33 d2 7d ea 64 906 c8 b6 4d 66 de c1 db ce 6d de a1 b3 a5 d3 12 c7 907 9a 0c e1 47 00 00 00 07 41 32 35 36 47 43 4d 00 908 00 00 03 42 6f 62 00 00 00 05 41 6c 69 63 65 00 909 00 01 00 911 The resulting derived key, which is the full 256-bits of the round 1 912 hash output is: 914 7c 22 e5 61 29 89 74 7f 4e d3 b1 94 30 e1 7d 3c 915 98 14 5c 77 15 5c 71 6a 9d 5d f8 5b ea dd 79 02 917 Bob then generates a random 96-bit IV for A256GCM. In hexadecimal 918 format: 920 cd 9f b1 e1 48 cc d8 44 2e 5a a7 49 922 Bob uses the derived key and the IV to encrypt and authenticate the 923 following plaintext JWT Claims Set, with the octets of the encoded 924 JWE Protected Header as the Additional Authenticated Data. 926 {"msg":"Hello Joe","aud":"Alice","iss":"Bob"} 928 In hexadecimal notation, the UTF-8 bytes of this plaintext are: 930 7b 22 6d 73 67 22 3a 22 48 65 6c 6c 6f 20 4a 6f 931 65 22 2c 22 61 75 64 22 3a 22 41 6c 69 63 65 22 932 2c 22 69 73 73 22 3a 22 42 6f 62 22 7d 934 The resulting Authentication Tag value is: 936 89 4c a4 f1 a7 7a d0 7b f0 d4 7c da 65 8b d3 95 938 The JWE Ciphertext is: 940 02 0d 16 b0 17 d4 8e 04 d2 f4 04 17 09 17 6a 6c 941 15 57 39 57 c8 ad 16 0c b4 b8 f1 c1 50 18 7d a1 942 ef cc b2 d1 da 6b 92 b0 32 bb a1 8b 64 944 Bob assembles the complete message in JWE Compact Serialization 945 format and sends it to Alice (with line breaks added for display 946 purposes only): 948 eyJ0eXAiOiJKV1QiLCJlcGsiOnsia3R5IjoiT0tQIiwiY3J 949 2IjoiWDQ0OCIsIngiOiJfYTRsRzBFVk82MnB5Vnl1R2pDSX 950 pIWUlJN3ZqRUJxZjAyQ2NOTUNIVWpXdlJNS2JrWkItWFEwd 951 XpoQnlYbGp4MGJOZ3BBdm1mODQifSwiYXB2IjoiUVd4cFky 952 VSIsImFwdSI6IlFtOWkiLCJraWQiOiJhbGljZS1lcGhlbWV 953 yYWwiLCJlbmMiOiJBMjU2R0NNIiwiYWxnIjoiRUNESC0xUF 954 UifQ..zZ-x4UjM2EQuWqdJ.Ag0WsBfUjgTS9AQXCRdqbBVX 955 OVfIrRYMtLjxwVAYfaHvzLLR2muSsDK7oYtk.iUyk8ad60H 956 vw1HzaZYvTlQ 958 Appendix C. Document History 960 -01 Added examples in Appendix A and Appendix B. Added "skid" 961 Header Parameter and registration. Fleshed out Security 962 Considerations. 964 Author's Address 966 Neil Madden 967 ForgeRock 968 Broad Quay House 969 Prince Street 970 Bristol BS1 4DJ 971 United Kingdom 973 Email: neil.madden@forgerock.com