-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathjose-ecdh-1pu.xml
1238 lines (1236 loc) · 64.8 KB
/
jose-ecdh-1pu.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-madden-jose-ecdh-1pu-05" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3" consensus="true">
<!-- xml2rfc v2v3 conversion 3.7.0 -->
<front>
<title abbrev="JOSE ECDH-1PU">Public Key Authenticated Encryption for JOSE: ECDH-1PU</title>
<seriesInfo name="Internet-Draft" value="draft-madden-jose-ecdh-1pu-05"/>
<author initials="N.E." surname="Madden" fullname="Neil Madden">
<organization>ForgeRock</organization>
<address>
<postal>
<street>Broad Quay House</street>
<street>Prince Street</street>
<city>Bristol</city>
<code>BS1 4DJ</code>
<country>United Kingdom</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="6" month="May" year="2021"/>
<area>Security</area>
<keyword>Internet-Draft</keyword>
<keyword>JSON Object Signing and Encryption</keyword>
<keyword>JOSE</keyword>
<keyword>JSON Web Encryption</keyword>
<keyword>JWE</keyword>
<keyword>JSON Web Algorithms</keyword>
<keyword>JWA</keyword>
<keyword>Elliptic Curve Diffie-Hellman Key Agreement</keyword>
<keyword>ECDH</keyword>
<keyword>ECDH-1PU</keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" numbered="true" toc="default">
<name>Introduction</name>
<t>
JSON Object Signing and Encryption (JOSE) defines a number of encryption (JWE)
<xref target="RFC7516" format="default"/> and digital signature (JWS) <xref target="RFC7515" format="default"/>
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.
</t>
<t>
ECDH-1PU is based on the One-Pass Unified Model for Elliptic Curve Diffie-Hellman
key agreement described in <xref target="NIST.800-56A" format="default"/>.
</t>
<t>
The advantages of public key authenticated encryption with ECDH-1PU compared to
using nested signed-then-encrypted documents include the following:
</t>
<ul spacing="normal">
<li>
The resulting message size is more compact as an additional layer of headers
and base64url-encoding is avoided. A 500-byte payload when encrypted and
authenticated with ECDH-1PU (with P-256 keys and "A256GCM" Content Encryption
Method) results in a 1087-byte JWE in Compact Encoding. An equivalent nested
signed-then-encrypted JOSE message using the same keys and encryption method
is 1489 bytes (37% larger).
</li>
<li>
The same primitives are used for both confidentiality and authenticity,
providing savings in code size for constrained environments.
</li>
<li>
The generic composition of signatures and public key encryption involves
a number of subtle details that are essential to security <xref target="PKAE" format="default"/>.
Providing a dedicated algorithm for public key authenticated encryption
reduces complexity for users of JOSE libraries.
</li>
<li>
ECDH-1PU provides only authenticity and not the stronger security properties of
non-repudiation or third-party verifiability. This can be an advantage in
applications where privacy, anonymity, or plausible deniability are goals.
</li>
</ul>
<section numbered="true" toc="default">
<name>Requirements Terminology</name>
<t>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 <xref target="RFC8174" format="default"/> when, and only when, they appear
in all capitals, as shown here.</t>
</section>
</section>
<section anchor="ecdh-1pu" numbered="true" toc="default">
<name>Key Agreement with Elliptic Curve Diffie-Hellman One-Pass Unified Model (ECDH-1PU)</name>
<t>
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 <xref target="NIST.800-56A" format="default"/> 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 <xref target="RFC7518" format="default"/>. As for ECDH-ES,
the key agreement result can be used in one of two ways:
</t>
<ol spacing="normal" type="1"><li>directly as the Content Encryption Key (CEK) for the "enc" algorithm, in the
Direct Key Agreement mode, or</li>
<li>as a symmetric key used to wrap the CEK with the "A128KW", "A192KW", or "A256KW"
algorithms, in the Key Agreement with Key Wrapping mode.</li>
</ol>
<t>
A fresh ephemeral public key value MUST be generated for each message. When encrypting
the message to multiple recipients using ECDH-1PU, the same ephemeral keys MAY be reused
for multiple recipients <xref target="MRES" format="default"/>.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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:
</t>
<table align="center">
<thead>
<tr>
<th align="left">"alg" Param Value</th>
<th align="left">Key Management Algorithm</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">ECDH-1PU+A128KW</td>
<td align="left">ECDH-1PU using one-pass KDF and CEK wrapped with "A128KW"</td>
</tr>
<tr>
<td align="left">ECDH-1PU+A192KW</td>
<td align="left">ECDH-1PU using one-pass KDF and CEK wrapped with "A192KW"</td>
</tr>
<tr>
<td align="left">ECDH-1PU+A256KW</td>
<td align="left">ECDH-1PU using one-pass KDF and CEK wrapped with "A256KW"</td>
</tr>
</tbody>
</table>
<section numbered="true" toc="default">
<name>Special Considerations for Key Agreement with Key Wrapping mode</name>
<t>
In Key Agreement with Key Wrapping mode, the JWE Authentication Tag is included in the
input to the Key Derivation Function as described in section <xref target="kdf" format="default"/>. This
ensures that the content of the JWE was produced by the original sender and not by
another recipient, as described in section <xref target="security" format="default"/>.
</t>
<t>
Key Agreement with Key Wrapping mode MUST only be used with content encryption algorithms
that are compactly committing AEADs as described in <xref target="ccAEAD" format="default"/>. The
AES_CBC_HMAC_SHA2 algorithms described in section 5.2 of <xref target="RFC7518" format="default"/> are
compactly committing and can be used with ECDH-1PU in Key Agreement with Key Wrapping mode.
Other content encryption algorithms MUST be rejected. In Direct Key Agreement mode, any
JWE content encryption algorithm MAY be used.
</t>
<t>
The requirement to include the JWE Authentication Tag in the input to the Key Derivation
Function implies an adjustment to the order of operations performed during JWE Message
Encryption described in section 5.1 of <xref target="RFC7516" format="default"/>. Steps 3-8 are deferred
until after step 15, using the randomly generated CEK from step 2 for encryption of the
message content.
</t>
</section>
<section numbered="true" toc="default">
<name>Header Parameters used for ECDH Key Agreement</name>
<t>
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
<xref target="RFC7518" format="default"/>.
</t>
<t>
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.
</t>
<section anchor="skid" numbered="true" toc="default">
<name>"skid" Header Parameter</name>
<t>
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 <xref target="RFC7517" format="default"/>.
</t>
</section>
</section>
<section anchor="kdf" numbered="true" toc="default">
<name>Key Derivation for ECDH-1PU Key Agreement</name>
<t>
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 <xref target="NIST.800-56A" format="default"/>.
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 <xref target="NIST.800-56A" format="default"/> 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 <xref target="RFC7748" format="default"/> is used.
</t>
<t>
Key derivation is performed using the one-step KDF, as defined in Section 5.8.1 and
Section 5.8.2.1 of <xref target="NIST.800-56A" format="default"/> 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:
</t>
<dl newline="false" spacing="normal">
<dt>Z</dt>
<dd>
This is set to the representation of the shared secret Z as an octet sequence.
As per Section 6.2.1.2 of <xref target="NIST.800-56A" format="default"/> Z is the concatenation
of Ze and Zs, where Ze is the shared secret derived from applying the ECDH
primitive to the sender's ephemeral private key and the recipient's static
public key (when sending) or the recipient's static private key and the sender's
ephemeral public key (when receiving). Zs is the shared secret derived from
applying the ECDH primitive to the sender's static private key and the recipient's
static public key (when sending) or the recipient's static private key and the
sender's static public key (when receiving).
</dd>
<dt>keydatalen</dt>
<dd>
This is set to the number of bits in the desired output key. For "ECDH-1PU",
this is the length of the key used by the "enc" algorithm. For "ECDH-1PU+A128KW",
"ECDH-1PU+A192KW", and "ECDH-1PU+A256KW", this is 128, 192, and 256, respectively.
</dd>
<dt>cctag</dt>
<dd>
In Direct Key Agreement mode this is set to an empty octet string. In Key Agreement
with Key Wrapping mode, this is set to a value of the form Datalen || Data, where Data
is the raw octets of the JWE Authentication Tag, and Datalen is the big-endian 32-bit
length of the authentication tag (in octets).
</dd>
<dt>AlgorithmID</dt>
<dd>
The AlgorithmID value is of the form Datalen || Data, where Data is a variable-length
string of zero or more octets, and Datalen is a fixed-length, big-endian 32-bit counter
that indicates the length (in octets) of Data. In the Direct Key Agreement case,
Data is set to the octets of the ASCII representation of the "enc" Header Parameter value.
In the Key Agreement with Key Wrapping case, Data is set to the octets of the ASCII
representation of the "alg" (algorithm) Header Parameter value.
</dd>
<dt>PartyUInfo</dt>
<dd>
The PartyUInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apu" (agreement PartyUInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apu" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
</dd>
<dt>PartyVInfo</dt>
<dd>
The PartyVInfo value is of the form Datalen || Data, where Data is
a variable-length string of zero or more octets, and Datalen is a
fixed-length, big-endian 32-bit counter that indicates the length
(in octets) of Data. If an "apv" (agreement PartyVInfo) Header
Parameter is present, Data is set to the result of base64url
decoding the "apv" value and Datalen is set to the number of
octets in Data. Otherwise, Datalen is set to 0 and Data is set to
the empty octet sequence.
</dd>
<dt>SuppPubInfo</dt>
<dd>
This is set to the keydatalen represented as a 32-bit big-endian integer
followed by the octets of the cctag.
</dd>
<dt>SuppPrivInfo</dt>
<dd>
This is set to the empty octet sequence.
</dd>
</dl>
<t>
Applications need to specify 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 <xref target="NIST.800-56A" format="default"/> need to provide values that meet the requirements
of that document, e.g., by using values that identify the producer and consumer.
</t>
<t>
See <xref target="exampleA" format="default"/> for an example key agreement computation using Direct Key Agreement
mode, and <xref target="exampleB" format="default"/> for an example sending to multiple recipients using Key
Agreement with Key Wrapping mode.
</t>
</section>
</section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA considerations</name>
<t>
This section registers identifiers under the IANA JSON Web Signature and Encryption Algorithms
Registry established by <xref target="RFC7518" format="default"/> and the IANA JSON Web Signature and Encryption
Header Parameters registry established by <xref target="RFC7515" format="default"/>.
</t>
<section numbered="true" toc="default">
<name>JSON Web Signature and Encryption Algorithms Registration</name>
<t>
This section registers JWE algorithms as per the registry established in
<xref target="RFC7518" format="default"/>.
</t>
<section numbered="true" toc="default">
<name>ECDH-1PU</name>
<ul spacing="compact">
<li>Algorithm Name: "ECDH-1PU"</li>
<li>Algorithm Description: ECDH One-Pass Unified Model using one-pass KDF</li>
<li>Algorithm Usage Location(s): "alg"</li>
<li>JOSE Implementation Requirements: Optional</li>
<li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="ecdh-1pu" format="default"/></li>
<li>Algorithm Analysis Document(s): <xref target="NIST.800-56A" format="default"/> (Section 7.3),
<xref target="PKAE" format="default"/></li>
</ul>
<ul spacing="compact">
<li>Algorithm Name: "ECDH-1PU+A128KW"</li>
<li>Algorithm Description: ECDH One-Pass Unified Model using one-pass KDF and "A128KW"</li>
<li>Algorithm Usage Location(s): "alg"</li>
<li>JOSE Implementation Requirements: Optional</li>
<li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="ecdh-1pu" format="default"/></li>
<li>Algorithm Analysis Document(s): <xref target="NIST.800-56A" format="default"/> (Section 7.3),
<xref target="PKAE" format="default"/></li>
</ul>
<ul spacing="compact">
<li>Algorithm Name: "ECDH-1PU+A192KW"</li>
<li>Algorithm Description: ECDH One-Pass Unified Model using one-pass KDF and "A192KW"</li>
<li>Algorithm Usage Location(s): "alg"</li>
<li>JOSE Implementation Requirements: Optional</li>
<li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="ecdh-1pu" format="default"/></li>
<li>Algorithm Analysis Document(s): <xref target="NIST.800-56A" format="default"/> (Section 7.3),
<xref target="PKAE" format="default"/></li>
</ul>
<ul spacing="compact">
<li>Algorithm Name: "ECDH-1PU+A256KW"</li>
<li>Algorithm Description: ECDH One-Pass Unified Model using one-pass KDF and "A256KW"</li>
<li>Algorithm Usage Location(s): "alg"</li>
<li>JOSE Implementation Requirements: Optional</li>
<li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="ecdh-1pu" format="default"/></li>
<li>Algorithm Analysis Document(s): <xref target="NIST.800-56A" format="default"/> (Section 7.3),
<xref target="PKAE" format="default"/></li>
</ul>
</section>
</section>
<section numbered="true" toc="default">
<name>JSON Web Signature and Encryption Header Parameters Registration</name>
<t>
This section registers new Header Parameters as per the registry established in
<xref target="RFC7515" format="default"/>.
</t>
<section numbered="true" toc="default">
<name>skid</name>
<ul spacing="compact">
<li>Header Parameter Name: "skid"</li>
<li>Header Parameter Description: Sender Key ID</li>
<li>Header Parameter Usage Location(s): JWE</li>
<li>Change Controller: IESG</li>
<li>Specification Document(s): <xref target="skid" format="default"/></li>
</ul>
</section>
</section>
</section>
<section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name>
<t>
The security considerations of <xref target="RFC7516" format="default"/> and <xref target="RFC7518" format="default"/>
relevant to ECDH-ES also apply to this specification.
</t>
<t>The security considerations of <xref target="NIST.800-56A" format="default"/> apply here.</t>
<t>
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 <xref target="NIST.800-56A" format="default"/>. For the curves
used by X25519 and X448, consult the security considerations of <xref target="RFC7748" format="default"/>.
</t>
<t>
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. If resistance to KCI is desired in a single
message, then the sender SHOULD use a nested JWS signature over the content.
</t>
<t>
When Key Agreement with Key Wrapping is used, the JWE Authentication Tag is included in
the input to the Key Derivation Function, as described in section <xref target="kdf" format="default"/>.
Without this step, when the same Content Encryption Key (CEK) is reused for multiple
recipients, then any of those recipients can produce a new message that appears to come
from the original sender. If the MAC used by the content encryption algorithm is not
compactly committing (<xref target="ccAEAD" format="default"/>) then it may be possible for a recipient
to calculate an alternative message that produces the same authentication tag. An
alternative is to encrypt the message separately to each recipient using Direct Key
Agreement, or to sign the message using a nested signed-then-encrypted JOSE composition.
</t>
<t>
The security properties of the one-pass unified model are given in Section 7.3 of
<xref target="NIST.800-56A" format="default"/>.
</t>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="RFC7515" target="https://www.rfc-editor.org/info/rfc7515" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7515.xml">
<front>
<title>JSON Web Signature (JWS)</title>
<author initials="M." surname="Jones" fullname="M. Jones">
<organization/>
</author>
<author initials="J." surname="Bradley" fullname="J. Bradley">
<organization/>
</author>
<author initials="N." surname="Sakimura" fullname="N. Sakimura">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>JSON Web Signature (JWS) represents content secured with digital signatures or Message Authentication Codes (MACs) using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and an IANA registry defined by that specification. Related encryption capabilities are described in the separate JSON Web Encryption (JWE) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7515"/>
<seriesInfo name="DOI" value="10.17487/RFC7515"/>
</reference>
<reference anchor="RFC7516" target="https://www.rfc-editor.org/info/rfc7516" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7516.xml">
<front>
<title>JSON Web Encryption (JWE)</title>
<author initials="M." surname="Jones" fullname="M. Jones">
<organization/>
</author>
<author initials="J." surname="Hildebrand" fullname="J. Hildebrand">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>JSON Web Encryption (JWE) represents encrypted content using JSON-based data structures. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries defined by that specification. Related digital signature and Message Authentication Code (MAC) capabilities are described in the separate JSON Web Signature (JWS) specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7516"/>
<seriesInfo name="DOI" value="10.17487/RFC7516"/>
</reference>
<reference anchor="RFC7517" target="https://www.rfc-editor.org/info/rfc7517" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7517.xml">
<front>
<title>JSON Web Key (JWK)</title>
<author initials="M." surname="Jones" fullname="M. Jones">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>A JSON Web Key (JWK) is a JavaScript Object Notation (JSON) data structure that represents a cryptographic key. This specification also defines a JWK Set JSON data structure that represents a set of JWKs. Cryptographic algorithms and identifiers for use with this specification are described in the separate JSON Web Algorithms (JWA) specification and IANA registries established by that specification.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7517"/>
<seriesInfo name="DOI" value="10.17487/RFC7517"/>
</reference>
<reference anchor="RFC7518" target="https://www.rfc-editor.org/info/rfc7518" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7518.xml">
<front>
<title>JSON Web Algorithms (JWA)</title>
<author initials="M." surname="Jones" fullname="M. Jones">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>This specification registers cryptographic algorithms and identifiers to be used with the JSON Web Signature (JWS), JSON Web Encryption (JWE), and JSON Web Key (JWK) specifications. It defines several IANA registries for these identifiers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7518"/>
<seriesInfo name="DOI" value="10.17487/RFC7518"/>
</reference>
<reference anchor="RFC7748" target="https://www.rfc-editor.org/info/rfc7748" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml">
<front>
<title>Elliptic Curves for Security</title>
<author initials="A." surname="Langley" fullname="A. Langley">
<organization/>
</author>
<author initials="M." surname="Hamburg" fullname="M. Hamburg">
<organization/>
</author>
<author initials="S." surname="Turner" fullname="S. Turner">
<organization/>
</author>
<date year="2016" month="January"/>
<abstract>
<t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7748"/>
<seriesInfo name="DOI" value="10.17487/RFC7748"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="NIST.800-56A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar3.pdf">
<front>
<title>Recommendation for Pair-Wise Key Establishment Using Discrete Logarithm Cryptography Revision 3.</title>
<author surname="Barker" initials="E.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Chen" initials="L.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Roginsky" initials="A.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Vassilev" initials="A.">
<organization>Computer Security Division, Information Technology Laboratory</organization>
</author>
<author surname="Davis" initials="R.">
<organization>National Security Agency</organization>
</author>
<date month="April" year="2018"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-56A"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="PKAE" target="https://eprint.iacr.org/2001/079.ps">
<front>
<title>Authenticated Encryption in the Public-Key Setting: Security Notions and Analyses</title>
<author surname="An" initials="J.">
<organization>University of California at Davis</organization>
</author>
<date year="2001"/>
</front>
<seriesInfo name="IACR" value="ePrint 2001/079"/>
</reference>
<reference anchor="ccAEAD" target="https://eprint.iacr.org/2017/664.pdf">
<front>
<title>Message Franking via Committing Authenticated Encryption</title>
<author fullname="Paul Grubbs">
<organization>Cornell Tech</organization>
</author>
<author fullname="Jiahui Lu">
<organization>Shanghai Jiao Tong University</organization>
</author>
<author fullname="Thomas Ristenpart">
<organization>Cornell Tech</organization>
</author>
<date year="2017"/>
</front>
<seriesInfo name="IACR" value="ePrint 2017/664"/>
</reference>
<reference anchor="MRES" target="https://www.cc.gatech.edu/~aboldyre/papers/bbks.pdf">
<front>
<title>Multi-Recipient Encryption Schemes: Efficient Constructions and their Security</title>
<author surname="Bellare" initials="M.">
<organization>University of California at San Diego</organization>
</author>
<author surname="Boldyreva" initials="A.">
<organization>Georgia Institute of Technology</organization>
</author>
<author surname="Kurosawa" initials="K.">
<organization>Ibaraki University</organization>
</author>
<author surname="Staddon" initials="J.">
<organization>Palo Alto Research Center</organization>
</author>
<date year="2007"/>
</front>
<seriesInfo name="IEEE Transactions on Information Theory" value="Vol. 53, Number 11"/>
</reference>
<reference anchor="RFC8037" target="https://www.rfc-editor.org/info/rfc8037" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8037.xml">
<front>
<title>CFRG Elliptic Curve Diffie-Hellman (ECDH) and Signatures in JSON Object Signing and Encryption (JOSE)</title>
<author initials="I." surname="Liusvaara" fullname="I. Liusvaara">
<organization/>
</author>
<date year="2017" month="January"/>
<abstract>
<t>This document defines how to use the Diffie-Hellman algorithms "X25519" and "X448" as well as the signature algorithms "Ed25519" and "Ed448" from the IRTF CFRG elliptic curves work in JSON Object Signing and Encryption (JOSE).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8037"/>
<seriesInfo name="DOI" value="10.17487/RFC8037"/>
</reference>
</references>
</references>
<section anchor="exampleA" numbered="true" toc="default">
<name>Example ECDH-1PU Key Agreement Computation with A256GCM</name>
<t>
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 <xref target="RFC7518" format="default"/>, with the addition of an extra static key-pair for Alice.
</t>
<t>
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:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"WKn-ZIGevcwGIyyrzFoZNBdaq9_TsqzGl96oc0CWuis",
"y":"y77t-RvAHRKTsSGdIYUfweuOvwrvDD-Q3Hv5J0fSKbE",
"d":"Hndv7ZZjs_ke8o9zXYo3iq-Yr8SewI5vrqd0pAvEPqg"}
]]></artwork>
<t>
Bob's static key-pair (in JWK format) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
"y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
"d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"}
]]></artwork>
<t>
The producer (Alice) generates an ephemeral key for the key agreement computation.
Alice's ephemeral key (in JWK format) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps",
"d":"0_NxaRPUMQoAJt50Gz8YiTr8gRTwyEaCumd-MToTmIo"}
]]></artwork>
<t>
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).
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"alg":"ECDH-1PU",
"enc":"A256GCM",
"apu":"QWxpY2U",
"apv":"Qm9i",
"epk":
{"kty":"EC",
"crv":"P-256",
"x":"gI0GAILBdu7T53akrFmMyGcsF3n5dO7MmwNBHKW5SV0",
"y":"SLW_xSffzlPWrHEVI30DHM_4egVwt3NQqeUD7nMFpps"
}
}
]]></artwork>
<t>
The resulting one-pass KDF <xref target="NIST.800-56A" format="default"/> parameter values are:
</t>
<dl newline="false" spacing="compact">
<dt>Ze</dt>
<dd>
This is set to the output of the ECDH key agreement between Alice's
ephemeral private key and Bob's static public key. In this example,
Ze is the following octet sequence (in hexadecimal notation):
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
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]]></artwork>
<dl newline="false" spacing="compact">
<dt>Zs</dt>
<dd>
This is set to the output of the ECDH key agreement between Alice's
static private key and Bob's static public key. In this example,
Zs is the following octet sequence (in hexadecimal notation):
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
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]]></artwork>
<dl newline="false" spacing="compact">
<dt>Z</dt>
<dd>
This is set to the concatenation of Ze followed by Zs. In this example,
Z is the following octet sequence (in hexadecimal notation):
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
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]]></artwork>
<dl newline="false" spacing="compact">
<dt>keydatalen</dt>
<dd>
This value is 256 - the number of bits in the desired output key
(because "A256GCM" uses a 256-bit key).
</dd>
<dt>cctag</dt>
<dd>
This value is the empty octet string.
</dd>
<dt>AlgorithmID</dt>
<dd>
This is set to the octets representing the 32-bit big-endian value
7 - 00 00 00 07 in hexadecimal notation - the number of octets in
the AlgorithmID content "A256GCM", followed by the octets representing
the ASCII string "A256GCM" - 41 32 35 36 47 43 4d (in hex). The
complete value is therefore: 00 00 00 07 41 32 35 36 47 43 4d
</dd>
<dt>PartyUInfo</dt>
<dd>
This is set to the octets representing the 32-bit big-endian value
5, followed by the octets representing the UTF-8 string "Alice". In
hexadecimal notation: 00 00 00 05 41 6c 69 63 65
</dd>
<dt>PartyVInfo</dt>
<dd>
This is set to the octets representing the 32-bit big-endian value
3, followed by the octets representing the UTF-8 string "Bob". In
hexadecimal notation: 00 00 00 03 42 6f 62
</dd>
<dt>SuppPubInfo</dt>
<dd>
This is set to the octets representing the 32-bit big-endian value
256 - the keydatalen value. In hexadecimal notation: 00 00 01 00
</dd>
<dt>SuppPrivInfo</dt>
<dd>
This is set to the empty octet sequence.
</dd>
</dl>
<t>
Concatenating the parameters AlgorithmID through SuppPrivInfo results in a FixedInfo
value in Concatenation Format (as per Section 5.8.2.1.1 of <xref target="NIST.800-56A" format="default"/>)
of (in hexidecimal notation):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
]]></artwork>
<t>
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):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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 ]]></artwork>
<t>
The resulting derived key, which is the full 256 bits of the round 1 hash output is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
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
]]></artwork>
<t>
The base64url-encoded representation of this derived key is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
bK8Tcj0UhQrUtCzW3ek1v_0v_wCpunDeBcIDpeFyLKc
]]></artwork>
</section>
<section anchor="exampleB" numbered="true" toc="default">
<name>Example ECDH-1PU+A128KW Key Agreement computation with A256CBC-HS256</name>
<t>
This example uses ECDH-1PU in Key Agreement with Key Wrapping mode ("alg" value "ECDH-1PU+A128KW")
to encrypt a JWE for multiple recipients using the JWE JSON Serialization. The example uses
X25519 key pairs, as described in <xref target="RFC8037" format="default"/>. Alice is sending an identical message
to Bob and Charlie. Because Bob and Charlie are using the same curve (X25519), Alice reuses
the same ephemeral key-pair for both recipients and includes it in the JWE Protected Header. If this
was not the case, Alice should generate a separate ephemeral key-pair for each recipient and include
it in each per-recipient header instead.
</t>
<t>
Alice's static key pair, represented as an OKP JWK (including the private component) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty": "OKP",
"crv": "X25519",
"x": "Knbm_BcdQr7WIoz-uqit9M0wbcfEr6y-9UfIZ8QnBD4",
"d": "i9KuFhSzEBsiv3PKVL5115OCdsqQai5nj_Flzfkw5jU"}
]]></artwork>
<t>
Bob's static key-pair (in JWK format) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty": "OKP",
"crv": "X25519",
"x": "BT7aR0ItXfeDAldeeOlXL_wXqp-j5FltT0vRSG16kRw",
"d": "1gDirl_r_Y3-qUa3WXHgEXrrEHngWThU3c9zj9A2uBg"}
]]></artwork>
<t>
Charlie's static key-pair (in JWK format) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty": "OKP",
"crv": "X25519",
"x": "q-LsvU772uV_2sPJhfAIq-3vnKNVefNoIlvyvg1hrnE",
"d": "Jcv8gklhMjC0b-lsk5onBbppWAx5ncNtbM63Jr9xBQE"}
]]></artwork>
<t>
Alice generates an ephemeral key-pair on the same curve. Alice's ephemeral key-pair (in JWK
format) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kty": "OKP",
"crv": "X25519",
"x": "k9of_cpAajy0poW5gaixXGs9nHkwg1AFqUAFa39dyBc",
"d": "x8EVZH4Fwk673_mUujnliJoSrLz0zYzzCWp5GUX2fc8"}
]]></artwork>
<section numbered="true" toc="default">
<name>JWE Protected Header</name>
<t>
The JWE Protected Header is 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 and Charlie". The "epk"
(ephemeral public key) Header Parameter is used to communicate the producer's (Alice's) ephemeral
public key to the consumers (Bob and Charlie). Line breaks have been added only for display purposes.
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"alg":"ECDH-1PU+A128KW",
"enc":"A256CBC-HS512",
"apu":"QWxpY2U",
"apv":"Qm9iIGFuZCBDaGFybGll",
"epk":
{"kty":"OKP",
"crv":"X25519",
"x":"k9of_cpAajy0poW5gaixXGs9nHkwg1AFqUAFa39dyBc"}}
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>JWE Per-Recipient Unprotected Headers</name>
<t>
The following JWE Per-Recipient Unprotected Header values are used for Bob and Charlie respectively:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"kid":"bob-key-2"}
{"kid":"2021-05-06"}
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>JWE Shared Unprotected Header</name>
<t>
This JWE uses the "jku" Header Parameter to reference a JWK Set.
This is represented in the following JWE Shared Unprotected Header
value as:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
{"jku":"https://alice.example.com/keys.jwks"}
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Additional Authenticated Data</name>
<t>
Let the Additional Authenticated Data encryption parameter be ASCII(BASE64URL(UTF8(JWE Protected Header))).
This value is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
[123, 34, 97, 108, 103, 34, 58, 34, 69, 67, 68, 72, 45, 49,
80, 85, 43, 65, 49, 50, 56, 75, 87, 34, 44, 34, 101, 110,
99, 34, 58, 34, 65, 50, 53, 54, 67, 66, 67, 45, 72, 83,
53, 49, 50, 34, 44, 34, 97, 112, 117, 34, 58, 34, 81, 87,
120, 112, 89, 50, 85, 34, 44, 34, 97, 112, 118, 34, 58,
34, 81, 109, 57, 105, 73, 71, 70, 117, 90, 67, 66, 68,
97, 71, 70, 121, 98, 71, 108, 108, 34, 44, 34, 101, 112,
107, 34, 58, 123, 34, 107, 116, 121, 34, 58, 34, 79, 75,
80, 34, 44, 34, 99, 114, 118, 34, 58, 34, 88, 50, 53, 53,
49, 57, 34, 44, 34, 120, 34, 58, 34, 107, 57, 111, 102,
95, 99, 112, 65, 97, 106, 121, 48, 112, 111, 87, 53, 103,
97, 105, 120, 88, 71, 115, 57, 110, 72, 107, 119, 103,
49, 65, 70, 113, 85, 65, 70, 97, 51, 57, 100, 121, 66,
99, 34, 125, 125]
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Content Encryption Key</name>
<t>
Alice generates the following 512-bit Content Encryption Key (CEK) for A256CBC-HS512 (shown in hexadecimal):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
ff fe fd fc fb fa f9 f8 f7 f6 f5 f4 f3 f2 f1 f0
ef ee ed ec eb ea e9 e8 e7 e6 e5 e4 e3 e2 e1 e0
df de dd dc db da d9 d8 d7 d6 d5 d4 d3 d2 d1 d0
cf ce cd cc cb ca c9 c8 c7 c6 c5 c4 c3 c2 c1 c0
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Initialization Vector</name>
<t>
She then generates the following random JWE Initialization Vector (IV):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
00 01 02 03 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>JWE Plaintext</name>
<t>
The plaintext of the message Alice sends to Bob and Charlie is the UTF-8 bytes of the
string "Three is a magic number." (without the quotes). The octets of the plaintext are:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
[84, 104, 114, 101, 101, 32, 105, 115, 32, 97, 32, 109, 97,
103, 105, 99, 32, 110, 117, 109, 98, 101, 114, 46]
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Content Encryption</name>
<t>
Alice performs authenticated encryption on the plaintext with the AES_256_CBC_HMAC_SHA_512 algorithm
using the CEK as the encryption key, the JWE Initialization Vector, and the Additional Authenticated
Data value above. This algorithm is described in <xref target="RFC7518" format="default"/>. The resulting ciphertext
(in base64url encoding) is:
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
Az2IWsISEMDJvyc5XRL-3-d-RgNBOGolCsxFFoUXFYw
]]></artwork>
<t>
The resulting JWE Authentication Tag is (in base64url encoding):
</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
HLb4fTlm8spGmij3RyOs2gJ4DpHM4hhVRwdF_hGb3WQ
]]></artwork>
</section>
<section numbered="true" toc="default">
<name>Key Agreement for Bob</name>
<t>
The KDF input parameters for Bob are as follows:
</t>
<dl newline="false" spacing="compact">
<dt>Ze</dt>
<dd>
This is set to the ECDH key agreement output between Alice's
ephemeral private key and Bob's static public key. In this
example, Ze is the following octet sequence (in hexadecimal):
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
32 81 08 96 e0 fe 4d 57 0e d1 ac fc ed f6 71 17
dc 19 4e d5 da ac 21 d8 ff 7a f3 24 46 94 89 7f
]]></artwork>
<dl newline="false" spacing="compact">
<dt>Zs</dt>
<dd>
This is set to the ECDH key agreement output between Alice's
static private key and Bob's static public key. In this example,
Zs is the following octet sequence (in hexadecimal):
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
21 57 61 2c 90 48 ed fa e7 7c b2 e4 23 71 40 60
59 67 c0 5c 7f 77 a4 8e ea f2 cf 29 a5 73 7c 4a
]]></artwork>
<dl newline="false" spacing="compact">
<dt>Z</dt>
<dd>
Z is the concatenation of Ze followed by Zs. In this example, the
value of Z is:
</dd>
</dl>
<artwork name="" type="" align="left" alt=""><![CDATA[
32 81 08 96 e0 fe 4d 57 0e d1 ac fc ed f6 71 17
dc 19 4e d5 da ac 21 d8 ff 7a f3 24 46 94 89 7f
21 57 61 2c 90 48 ed fa e7 7c b2 e4 23 71 40 60
59 67 c0 5c 7f 77 a4 8e ea f2 cf 29 a5 73 7c 4a
]]></artwork>
<dl newline="false" spacing="compact">
<dt>keydatalen</dt>
<dd>
This value is 128 - the number of bits in the desired output key