-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ounsworth-pq-composite-encryption.html
1125 lines (1022 loc) · 60.9 KB
/
draft-ounsworth-pq-composite-encryption.html
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
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head profile="http://www.w3.org/2006/03/hcard http://dublincore.org/documents/2008/08/04/dc-html/">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<title>Composite Encryption For Use In Internet PKI</title>
<style type="text/css" title="Xml2Rfc (sans serif)">
/*<![CDATA[*/
a {
text-decoration: none;
}
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a.smpl {
color: black;
}
a:hover {
text-decoration: underline;
}
a:active {
text-decoration: underline;
}
address {
margin-top: 1em;
margin-left: 2em;
font-style: normal;
}
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 10pt;
max-width: 55em;
}
cite {
font-style: normal;
}
dd {
margin-right: 2em;
}
dl {
margin-left: 2em;
}
ul.empty {
list-style-type: none;
}
ul.empty li {
margin-top: .5em;
}
dl p {
margin-left: 0em;
}
dt {
margin-top: .5em;
}
h1 {
font-size: 14pt;
line-height: 21pt;
page-break-after: avoid;
}
h1.np {
page-break-before: always;
}
h1 a {
color: #333333;
}
h2 {
font-size: 12pt;
line-height: 15pt;
page-break-after: avoid;
}
h3, h4, h5, h6 {
font-size: 10pt;
page-break-after: avoid;
}
h2 a, h3 a, h4 a, h5 a, h6 a {
color: black;
}
img {
margin-left: 3em;
}
li {
margin-left: 2em;
margin-right: 2em;
}
ol {
margin-left: 2em;
margin-right: 2em;
}
ol p {
margin-left: 0em;
}
p {
margin-left: 2em;
margin-right: 2em;
}
pre {
margin-left: 3em;
background-color: lightyellow;
padding: .25em;
}
pre.text2 {
border-style: dotted;
border-width: 1px;
background-color: #f0f0f0;
width: 69em;
}
pre.inline {
background-color: white;
padding: 0em;
}
pre.text {
border-style: dotted;
border-width: 1px;
background-color: #f8f8f8;
width: 69em;
}
pre.drawing {
border-style: solid;
border-width: 1px;
background-color: #f8f8f8;
padding: 2em;
}
table {
margin-left: 2em;
}
table.tt {
vertical-align: top;
}
table.full {
border-style: outset;
border-width: 1px;
}
table.headers {
border-style: outset;
border-width: 1px;
}
table.tt td {
vertical-align: top;
}
table.full td {
border-style: inset;
border-width: 1px;
}
table.tt th {
vertical-align: top;
}
table.full th {
border-style: inset;
border-width: 1px;
}
table.headers th {
border-style: none none inset none;
border-width: 1px;
}
table.left {
margin-right: auto;
}
table.right {
margin-left: auto;
}
table.center {
margin-left: auto;
margin-right: auto;
}
caption {
caption-side: bottom;
font-weight: bold;
font-size: 9pt;
margin-top: .5em;
}
table.header {
border-spacing: 1px;
width: 95%;
font-size: 10pt;
color: white;
}
td.top {
vertical-align: top;
}
td.topnowrap {
vertical-align: top;
white-space: nowrap;
}
table.header td {
background-color: gray;
width: 50%;
}
table.header a {
color: white;
}
td.reference {
vertical-align: top;
white-space: nowrap;
padding-right: 1em;
}
thead {
display:table-header-group;
}
ul.toc, ul.toc ul {
list-style: none;
margin-left: 1.5em;
margin-right: 0em;
padding-left: 0em;
}
ul.toc li {
line-height: 150%;
font-weight: bold;
font-size: 10pt;
margin-left: 0em;
margin-right: 0em;
}
ul.toc li li {
line-height: normal;
font-weight: normal;
font-size: 9pt;
margin-left: 0em;
margin-right: 0em;
}
li.excluded {
font-size: 0pt;
}
ul p {
margin-left: 0em;
}
.comment {
background-color: yellow;
}
.center {
text-align: center;
}
.error {
color: red;
font-style: italic;
font-weight: bold;
}
.figure {
font-weight: bold;
text-align: center;
font-size: 9pt;
}
.filename {
color: #333333;
font-weight: bold;
font-size: 12pt;
line-height: 21pt;
text-align: center;
}
.fn {
font-weight: bold;
}
.hidden {
display: none;
}
.left {
text-align: left;
}
.right {
text-align: right;
}
.title {
color: #990000;
font-size: 18pt;
line-height: 18pt;
font-weight: bold;
text-align: center;
margin-top: 36pt;
}
.vcardline {
display: block;
}
.warning {
font-size: 14pt;
background-color: yellow;
}
@media print {
.noprint {
display: none;
}
a {
color: black;
text-decoration: none;
}
table.header {
width: 90%;
}
td.header {
width: 50%;
color: black;
background-color: white;
vertical-align: top;
font-size: 12pt;
}
ul.toc a::after {
content: leader('.') target-counter(attr(href), page);
}
ul.ind li li a {
content: target-counter(attr(href), page);
}
.print2col {
column-count: 2;
-moz-column-count: 2;
column-fill: auto;
}
}
@page {
@top-left {
content: "Internet-Draft";
}
@top-right {
content: "December 2010";
}
@top-center {
content: "Abbreviated Title";
}
@bottom-left {
content: "Doe";
}
@bottom-center {
content: "Expires June 2011";
}
@bottom-right {
content: "[Page " counter(page) "]";
}
}
@page:first {
@top-left {
content: normal;
}
@top-right {
content: normal;
}
@top-center {
content: normal;
}
}
/*]]>*/
</style>
<link href="#rfc.toc" rel="Contents">
<link href="#rfc.section.1" rel="Chapter" title="1 Introduction">
<link href="#rfc.section.1.1" rel="Chapter" title="1.1 Terminology">
<link href="#rfc.section.2" rel="Chapter" title="2 Composite Key Transport using Encryption primitives">
<link href="#rfc.section.2.1" rel="Chapter" title="2.1 Algorithm Identifier">
<link href="#rfc.section.2.2" rel="Chapter" title="2.2 Public key and key usage">
<link href="#rfc.section.2.2.1" rel="Chapter" title="2.2.1 Composite-OR">
<link href="#rfc.section.2.3" rel="Chapter" title="2.3 Algorithm parameters">
<link href="#rfc.section.2.4" rel="Chapter" title="2.4 Encryption process">
<link href="#rfc.section.2.5" rel="Chapter" title="2.5 Decryption process">
<link href="#rfc.section.3" rel="Chapter" title="3 Composite Key Transport using Encryption and KEM primitives">
<link href="#rfc.section.3.1" rel="Chapter" title="3.1 Algorithm Identifier">
<link href="#rfc.section.3.2" rel="Chapter" title="3.2 Public key and key usage">
<link href="#rfc.section.3.2.1" rel="Chapter" title="3.2.1 Composite-OR">
<link href="#rfc.section.3.3" rel="Chapter" title="3.3 Algorithm parameters">
<link href="#rfc.section.3.4" rel="Chapter" title="3.4 Encryption process">
<link href="#rfc.section.3.5" rel="Chapter" title="3.5 Decryption process">
<link href="#rfc.section.4" rel="Chapter" title="4 Composite Key Exchange">
<link href="#rfc.section.4.1" rel="Chapter" title="4.1 Algorithm Identifier">
<link href="#rfc.section.4.2" rel="Chapter" title="4.2 Public key and key usage">
<link href="#rfc.section.4.2.1" rel="Chapter" title="4.2.1 Composite-OR">
<link href="#rfc.section.4.3" rel="Chapter" title="4.3 Algorithm parameters">
<link href="#rfc.section.4.4" rel="Chapter" title="4.4 Encapsulation Process">
<link href="#rfc.section.4.5" rel="Chapter" title="4.5 Decapsulation Process">
<link href="#rfc.section.5" rel="Chapter" title="5 In Practice">
<link href="#rfc.section.6" rel="Chapter" title="6 IANA Considerations">
<link href="#rfc.section.7" rel="Chapter" title="7 Security Considerations">
<link href="#rfc.section.7.1" rel="Chapter" title="7.1 IID property of KEM primitives">
<link href="#rfc.section.7.2" rel="Chapter" title="7.2 Composite-OR modes">
<link href="#rfc.section.7.3" rel="Chapter" title="7.3 Policy for Deprecated or Unacceptable Algorithms">
<link href="#rfc.section.8" rel="Chapter" title="8 Appendices">
<link href="#rfc.section.8.1" rel="Chapter" title="8.1 ASN.1 Module">
<link href="#rfc.section.8.2" rel="Chapter" title="8.2 Intellectual Property Considerations">
<link href="#rfc.section.8.3" rel="Chapter" title="8.3 Making contributions">
<link href="#rfc.references" rel="Chapter" title="9 Normative References">
<link href="#rfc.authors" rel="Chapter">
<meta name="generator" content="xml2rfc version 2.40.0 - https://tools.ietf.org/tools/xml2rfc" />
<link rel="schema.dct" href="http://purl.org/dc/terms/" />
<meta name="dct.creator" content="Ounsworth, M., Gray, J., and S. Mister" />
<meta name="dct.identifier" content="urn:ietf:id:draft-ounsworth-pq-composite-encryption-01" />
<meta name="dct.issued" scheme="ISO8601" content="2022-02-12" />
<meta name="dct.abstract" content="With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite encryption data. This document defines a content encryption process following the hybrid model as described in the NIST Post-Quantum Crypto FAQ. This draft defines three composite encryption modes. First, Composite Key Transport using Encryption primitives which encrypts a message (typically a content encryption key) for a recipient with a composite public key composed entirely of encryption keys by encrypting it with multiple one-time-pad keys, each encrypted under a different recipient public key. Second, Composite Key Transport using Encryption and KEM primitives is the generalization of the previous mode to support a mixture of encryption and KEM algorithms. Third, Composite Key Exchange is the most general and supports establishing a shared secret using any combination of encryption, KEM, and key exchange primitives where a master shared secret is generated using NIST SP 800-56Cr2. " />
<meta name="description" content="With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite encryption data. This document defines a content encryption process following the hybrid model as described in the NIST Post-Quantum Crypto FAQ. This draft defines three composite encryption modes. First, Composite Key Transport using Encryption primitives which encrypts a message (typically a content encryption key) for a recipient with a composite public key composed entirely of encryption keys by encrypting it with multiple one-time-pad keys, each encrypted under a different recipient public key. Second, Composite Key Transport using Encryption and KEM primitives is the generalization of the previous mode to support a mixture of encryption and KEM algorithms. Third, Composite Key Exchange is the most general and supports establishing a shared secret using any combination of encryption, KEM, and key exchange primitives where a master shared secret is generated using NIST SP 800-56Cr2. " />
</head>
<body>
<table class="header">
<tbody>
<tr>
<td class="left">LAMPS</td>
<td class="right">M. Ounsworth</td>
</tr>
<tr>
<td class="left">Internet-Draft</td>
<td class="right">J. Gray</td>
</tr>
<tr>
<td class="left">Intended status: Standards Track</td>
<td class="right">S. Mister</td>
</tr>
<tr>
<td class="left">Expires: August 16, 2022</td>
<td class="right">Entrust</td>
</tr>
<tr>
<td class="left"></td>
<td class="right">February 12, 2022</td>
</tr>
</tbody>
</table>
<p class="title">Composite Encryption For Use In Internet PKI<br />
<span class="filename">draft-ounsworth-pq-composite-encryption-01</span></p>
<h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
<p>With the widespread adoption of post-quantum cryptography will come the need for an entity to possess multiple public keys on different cryptographic algorithms. Since the trustworthiness of individual post-quantum algorithms is at question, a multi-key cryptographic operation will need to be performed in such a way that breaking it requires breaking each of the component algorithms individually. This requires defining new structures for holding composite encryption data.</p>
<p>This document defines a content encryption process following the hybrid model as described in the NIST Post-Quantum Crypto FAQ. This draft defines three composite encryption modes. First, Composite Key Transport using Encryption primitives which encrypts a message (typically a content encryption key) for a recipient with a composite public key composed entirely of encryption keys by encrypting it with multiple one-time-pad keys, each encrypted under a different recipient public key. Second, Composite Key Transport using Encryption and KEM primitives is the generalization of the previous mode to support a mixture of encryption and KEM algorithms. Third, Composite Key Exchange is the most general and supports establishing a shared secret using any combination of encryption, KEM, and key exchange primitives where a master shared secret is generated using NIST SP 800-56Cr2.</p>
<h1 id="rfc.status"><a href="#rfc.status">Status of This Memo</a></h1>
<p>This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p>
<p>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/.</p>
<p>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."</p>
<p>This Internet-Draft will expire on August 16, 2022.</p>
<h1 id="rfc.copyrightnotice"><a href="#rfc.copyrightnotice">Copyright Notice</a></h1>
<p>Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
<p>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.</p>
<hr class="noprint" />
<h1 class="np" id="rfc.toc"><a href="#rfc.toc">Table of Contents</a></h1>
<ul class="toc">
<li>1. <a href="#rfc.section.1">Introduction</a>
</li>
<ul><li>1.1. <a href="#rfc.section.1.1">Terminology</a>
</li>
</ul><li>2. <a href="#rfc.section.2">Composite Key Transport using Encryption primitives</a>
</li>
<ul><li>2.1. <a href="#rfc.section.2.1">Algorithm Identifier</a>
</li>
<li>2.2. <a href="#rfc.section.2.2">Public key and key usage</a>
</li>
<ul><li>2.2.1. <a href="#rfc.section.2.2.1">Composite-OR</a>
</li>
</ul><li>2.3. <a href="#rfc.section.2.3">Algorithm parameters</a>
</li>
<li>2.4. <a href="#rfc.section.2.4">Encryption process</a>
</li>
<li>2.5. <a href="#rfc.section.2.5">Decryption process</a>
</li>
</ul><li>3. <a href="#rfc.section.3">Composite Key Transport using Encryption and KEM primitives</a>
</li>
<ul><li>3.1. <a href="#rfc.section.3.1">Algorithm Identifier</a>
</li>
<li>3.2. <a href="#rfc.section.3.2">Public key and key usage</a>
</li>
<ul><li>3.2.1. <a href="#rfc.section.3.2.1">Composite-OR</a>
</li>
</ul><li>3.3. <a href="#rfc.section.3.3">Algorithm parameters</a>
</li>
<li>3.4. <a href="#rfc.section.3.4">Encryption process</a>
</li>
<li>3.5. <a href="#rfc.section.3.5">Decryption process</a>
</li>
</ul><li>4. <a href="#rfc.section.4">Composite Key Exchange</a>
</li>
<ul><li>4.1. <a href="#rfc.section.4.1">Algorithm Identifier</a>
</li>
<li>4.2. <a href="#rfc.section.4.2">Public key and key usage</a>
</li>
<ul><li>4.2.1. <a href="#rfc.section.4.2.1">Composite-OR</a>
</li>
</ul><li>4.3. <a href="#rfc.section.4.3">Algorithm parameters</a>
</li>
<li>4.4. <a href="#rfc.section.4.4">Encapsulation Process</a>
</li>
<li>4.5. <a href="#rfc.section.4.5">Decapsulation Process</a>
</li>
</ul><li>5. <a href="#rfc.section.5">In Practice</a>
</li>
<li>6. <a href="#rfc.section.6">IANA Considerations</a>
</li>
<li>7. <a href="#rfc.section.7">Security Considerations</a>
</li>
<ul><li>7.1. <a href="#rfc.section.7.1">IID property of KEM primitives</a>
</li>
<li>7.2. <a href="#rfc.section.7.2">Composite-OR modes</a>
</li>
<li>7.3. <a href="#rfc.section.7.3">Policy for Deprecated or Unacceptable Algorithms</a>
</li>
</ul><li>8. <a href="#rfc.section.8">Appendices</a>
</li>
<ul><li>8.1. <a href="#rfc.section.8.1">ASN.1 Module</a>
</li>
<li>8.2. <a href="#rfc.section.8.2">Intellectual Property Considerations</a>
</li>
<li>8.3. <a href="#rfc.section.8.3">Making contributions</a>
</li>
</ul><li>9. <a href="#rfc.references">Normative References</a>
</li>
<li><a href="#rfc.authors">Authors' Addresses</a>
</li>
</ul>
<h1 id="rfc.section.1">
<a href="#rfc.section.1">1.</a> <a href="#sec-intro" id="sec-intro">Introduction</a>
</h1>
<p id="rfc.section.1.p.1">During the transition to post-quantum cryptography, there will be uncertainty as to the strength of cryptographic algorithms; we will no longer fully trust traditional cryptography such as RSA, Diffie-Hellman, DSA and their elliptic curve variants, but we will also not fully trust their post-quantum replacements until they have had sufficient scrutiny. Unlike previous cryptographic algorithm migrations, the choice of when to migrate and which algorithms to migrate to, is not so clear. Even after the migration period, it may be advantageous for an entity's cryptographic identity to be composed of key pairs associated with different public-key algorithms.</p>
<p id="rfc.section.1.p.2">The deployment of composite public keys and composite encryption using post-quantum algorithms will face two challenges:</p>
<p></p>
<ul>
<li>Algorithm strength uncertainty: During the transition period, some post-quantum signature and encryption algorithms will not be fully trusted, while the trust in legacy public key algorithms will start to erode. A relying party may learn some time after deployment that a public key algorithm has become untrustworthy, but in the interim, they may not know which algorithm an adversary has compromised.</li>
<li>Backwards compatibility: During the transition period, post-quantum algorithms will not be supported by all clients.</li>
</ul>
<p id="rfc.section.1.p.4">This document provides mechanisms to address algorithm strength uncertainty by building on ~~ reference draft-ounsworth-pq-composite-pubkeys ~~ by providing formats for both wrapping a content encryption key using multiple public key encryption mechanisms, or performing key exchange using a combination of encryption, key encapsulation, and key exchange primitives. The issue of backwards compatibility is addressed with support for Composite Or recipient keys in each mode.</p>
<p id="rfc.section.1.p.5">This document is intended for general applicability anywhere that content encryption or key exchange is used.</p>
<h1 id="rfc.section.1.1">
<a href="#rfc.section.1.1">1.1.</a> <a href="#sec-terminology" id="sec-terminology">Terminology</a>
</h1>
<p id="rfc.section.1.1.p.1">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 <a href="#RFC2119" class="xref">[RFC2119]</a> <a href="#RFC8174" class="xref">[RFC8174]</a> when, and only when, they appear in all capitals, as shown here.</p>
<p id="rfc.section.1.1.p.2">The following terms are used in this document:</p>
<p id="rfc.section.1.1.p.3">ALGORITHM: An information object class for identifying the type of cryptographic operation to be performed. This document is primarily concerned with algorithms for producing encryption keys.</p>
<p id="rfc.section.1.1.p.4">BER: Basic Encoding Rules (BER) as defined in <a href="#X.690" class="xref">[X.690]</a>.</p>
<p id="rfc.section.1.1.p.5">COMPONENT ALGORITHM: A single basic algorithm which is contained within a composite algorithm.</p>
<p id="rfc.section.1.1.p.6">COMPOSITE ALGORITHM: An algorithm which is a sequence of one or more component algorithms..</p>
<p id="rfc.section.1.1.p.7">DER: Distinguished Encoding Rules as defined in <a href="#X.690" class="xref">[X.690]</a>.</p>
<p id="rfc.section.1.1.p.8">PUBLIC / PRIVATE KEY: The public and private portion of an asymmetric cryptographic key, making no assumptions about which algorithm.</p>
<p id="rfc.section.1.1.p.9">PRIMITIVE PUBLIC KEY / SIGNATURE: A public key or signature object of a non-composite algorithm type.</p>
<p id="rfc.section.1.1.p.10">SIGNATURE: A digital cryptographic signature, making no assumptions about which algorithm.</p>
<p id="rfc.section.1.1.p.11">SECRET or SHARED SECRET: Cryptographic material established between two parties. May be generated by one party and send encrypted to the other, or may be the output of an exchange of public information between two or more parties that generates a unique shared value for all involved parties.</p>
<p id="rfc.section.1.1.p.12">KEY DERIVATION FUNCTION: A function used to derive secure secret keys using shared secrets, hashing and other cryptographic primitives.</p>
<p id="rfc.section.1.1.p.13">COMPOSITE ENCRYPTION KEY: A structure that contains a sequence of content encryption keys, or secrets used to derive a content encryption keys.</p>
<h1 id="rfc.section.2">
<a href="#rfc.section.2">2.</a> <a href="#sec-com-key-trans_encr" id="sec-com-key-trans_encr">Composite Key Transport using Encryption primitives</a>
</h1>
<p id="rfc.section.2.p.1">In this composite encryption mode, a message to be encrypted is provided by the calling application. This message to be encrypted is assumed to have length less than the maximum message size of the chosen encryption algorithms, as is the case when a suitably-sized symmetric key is encrypted.</p>
<p id="rfc.section.2.p.2">This mode is compatible with protocols requiring a key transport primitive, such as CMS' KeyTransRecipientInfo <a href="#RFC5652" class="xref">[RFC5652]</a>.</p>
<p id="rfc.section.2.p.3">Composite Key Transport using Encryption primitives uses a trivial XOR one-time-pad scheme, as defined in <a href="#sec-com-key-trans_encr_process" class="xref">Section 2.4</a>. It transports n one-time-pad secret keys of the same length as the content to be encryption, where n is the number of recipient component public keys, and each one-time-pad secret key is encrypted under a different recipient component public key. The trivial XOR key-sharing scheme requires the recipient to use all component private keys in order to recover the content encryption key. Note that it would be possible to use an "n of m" or "threshold" secret sharing scheme if it was desired for the recipient to be able to complete the key transport using a subset of their private keys, but that mechanism is not defined in this document.</p>
<p id="rfc.section.2.p.4">EDNOTE: we have not been able to find a reference and security analysis for the trivial XOR key-sharing scheme. This may need review by CFRG. We could re-frame this process as "a one-time pad with n-1 one-time pad keys, which we transport using the recipients public keys", then this could leverage one-time pad security analysis.</p>
<p id="rfc.section.2.p.5">Composite encryption uses the following structure:</p>
<p id="rfc.section.2.p.6">EDNOTE: Should a different composite OID be used to determine the type of composite encryption (Key Transport or Key Agreement?). Probably not because the desired key usage will be handled in the protocols that uses this privitive.</p>
<pre>
CompositeEncryptedKey ::= EncryptedKey{ SEQUENCE SIZE (2..Max) OF OCTET STRING}
</pre>
<p id="rfc.section.2.p.7">EDNOTE: This ASN.1 probably does not compile. The intent is that this fits into any EncryptedKey field, but defines some structure within the existing EncryptedKey ::= OCTET STRING, but I'm not sure exactly how to specify that.</p>
<p id="rfc.section.2.p.8">Where each OCTET STRING within the SEQUENCE contains an encrypted one-time-pad secret key encrypted under one of the recipient component public keys. The CompositeEncryptedKey MUST list encrypted values in the same order as the recipient public key's component keys.</p>
<h1 id="rfc.section.2.1">
<a href="#rfc.section.2.1">2.1.</a> <a href="#algorithm-identifier" id="algorithm-identifier">Algorithm Identifier</a>
</h1>
<p id="rfc.section.2.1.p.1">The id-alg-composite-encryption object identifier MUST be used to identify the usage of this mode</p>
<pre>
id-alg-composite-encryption OBJECT IDENTIFIER ::= {
id-alg-composite-encryption OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
Algorithm(80) Composite(4) id-alg-composite-encryption(4) }
</pre>
<p id="rfc.section.2.1.p.2">EDNOTE: this is a temporary OID for the purposes of prototyping. Permanent OIDs should be requested from IANA, see <a href="#sec-iana" class="xref">Section 6</a>.</p>
<h1 id="rfc.section.2.2">
<a href="#rfc.section.2.2">2.2.</a> <a href="#public-key-and-key-usage" id="public-key-and-key-usage">Public key and key usage</a>
</h1>
<p id="rfc.section.2.2.p.1">The recipient MUST have a composite public key which supports key transport operations. Where the recipient public key has an associated keyUsage as specified in <a href="#RFC5280" class="xref">[RFC5280]</a>, it MUST have keyUsage: keyEncipherment. In other words, the mechanism specified in this section applies only if all of the recipient's public keys are associated with encryption algorithms.</p>
<h1 id="rfc.section.2.2.1">
<a href="#rfc.section.2.2.1">2.2.1.</a> <a href="#composite-or" id="composite-or">Composite-OR</a>
</h1>
<p id="rfc.section.2.2.1.p.1">The design intent of this mode is to support migration scenarios where a recipient has been provisioned with a composite key containing algorithms that its peers may not yet support. This mode allows the sender to encrypt for a subset of the recipient's public keys. Support for Composite OR subset encryption is indicated by the recipient at key generation time by marking its composite key with the id-composite-or-key algorithm identifier as defined in ~~~cite properly draft-ounsworth-pq-composite-keys~~~. To maximize security strength of the ciphertext, clients SHOULD encrypt for as many keys as they support and as the migration and compatibility situation allow.</p>
<p id="rfc.section.2.2.1.p.2">Policy mechanisms defining allowed subets of algorithms could be applied here, but are out of scope of this document. As defined in this document, a recipient marking their public key as id-composite-or-key must accept the risk that a sender may encrypt sensitive data for it using any one of its component keys in isolation. Composite Or is a direct tradeoff of lower security for increased migration flexibility.</p>
<h1 id="rfc.section.2.3">
<a href="#rfc.section.2.3">2.3.</a> <a href="#sec-com-key-trans_encr-params" id="sec-com-key-trans_encr-params">Algorithm parameters</a>
</h1>
<p id="rfc.section.2.3.p.1">The composite key transport using encryption mode does not require additional parameters, and therefore any associated Params are ABSENT.</p>
<h1 id="rfc.section.2.4">
<a href="#rfc.section.2.4">2.4.</a> <a href="#sec-com-key-trans_encr_process" id="sec-com-key-trans_encr_process">Encryption process</a>
</h1>
<p id="rfc.section.2.4.p.1">The process for performing Composite Key Transport using Encryption primitives is as follows:</p>
<p id="rfc.section.2.4.p.2">The first n-1 one-time-pad keys are random bit strings of the same length as the content encryption key. The final one-time-pad key is computed by XOR'ing the content encryption key with each of n-1 previous keys.</p>
<pre>
Input:
n The number of recipient component public keys
P1, P2, .., Pn Recipient component public keys
A1, A2, .., An Cryptographic algorithms to be used with
public keys P1, P2, .., Pn
CEK The Content Encryption Key
SIZE The size of the Content Encryption Key in bits
Output:
E1, E2, .., En EncryptedKey values corresponding to each recipient
component public key
Intermediate values:
S1, S2, .., Sn-1 One-time-pad secret keys to be encapsulated by each
component algorithm
C One-time-pad ciphertext of the CEK under S1, S2, .., Sn-1
Generation Procedure:
1. If recipient public key is of type id-composite-or-key, determine the
index of the last recipient public key to be encrypted for
i_last := index of last Pi to be encrypted for
Else,
i_last = n
2. To generate secret keys Sn, compute the following
C = CEK
for i := 1 to n
a. If id-composite-or-key and Pi is to be skipped
Ei := emptyOctetString
continue to next i
b. If i == i_last
Ei = encrypt(C, Pi, Ai)
break
Else,
Si := random_bits(SIZE)
C := C XOR Si
Ei = encrypt(Si, Pi, Ai)
3. Output E1, E2, .., En
</pre>
<p id="rfc.section.2.4.p.3">Where <samp>random_bits(SIZE)</samp> is a cryptographically-secure random bit generator outputting SIZE bits, and where <samp>emptyOctetString</samp> is the octet string of length 0.</p>
<p id="rfc.section.2.4.p.4">EDNOTE: we currently do not define a composite algorithmID type to carry A1, A2, .., An. We may need to add one analogously to the CompositeParams ::= SEQUENCE SIZE (2..MAX) OF AlgorithmIdentifier that we have in the composite signutares draft.</p>
<p id="rfc.section.2.4.p.5">If the sender does not support Composite Or encryption, this algorithm may be simplified by omitting step 1, 2a, and the if i == i_last statement in 2b.</p>
<p id="rfc.section.2.4.p.6">The design intent is that Composite Or encryption with a single recipient key collapses to being equivalent to direct encryption of the CEK.</p>
<h1 id="rfc.section.2.5">
<a href="#rfc.section.2.5">2.5.</a> <a href="#sec-com-key-trans_decr_process" id="sec-com-key-trans_decr_process">Decryption process</a>
</h1>
<p id="rfc.section.2.5.p.1">To obtain the content-encryption key from a CompositeEncryptedKey, each component algorithm MUST be used to decrypt the set of one-time-pad keys. The keys are then XOR'ed together to recover the content encryption key.</p>
<pre>
Input:
n The number of recipient component public keys
SK1, SK2, .., SKn Recipient component secret keys
A1, A2, .., An Cryptographic algorithms to be used with
public keys P1, P2, .., Pn
E1, E2, .., En EncryptedKey values corresponding to each recipient
component public key
Intermediate values:
S1, S2, .., Sn One-time-pad keys and ciphertext to be decapsulated
by each component algorithm
Output:
CEK The Content Encryption Key
Generation Procedure:
1. Recover each one-time-pad key
for i := 1 to n
if Ei == emptyOctetString
Si := emptyOctetString
Else,
Si := decrypt(Ei, SKi)
2. Recover the CEK;
For each one-time-pad key
CEK = S1
for i := 2 to n
if Si != emptyOctetString
CEK = CEK XOR Si
3. Output CEK
</pre>
<p id="rfc.section.2.5.p.2">The if statement in step 1 (and ensuring its proper bit length for the XOR in step 2) is the only modification required to support Composite Or encryption. The designers have intentionally omitted a check that the recipient key is of type id-composite-or-key because even if the sender erroneously used composite or subset encryption for a recipient key which is not of type id-composite-or-key, the damage has already been done by encrypting and transmitting the data, no further harm can be done by decrypting it. However, where appropriate, clients SHOULD indicate a warning to users that this data was transmitted with weaker encrypting than their public key allows.</p>
<p id="rfc.section.2.5.p.3">EDNOTE: investigate whether this is actually a special case of the next mechanism, and therefore both sections can be folded together.</p>
<h1 id="rfc.section.3">
<a href="#rfc.section.3">3.</a> <a href="#sec-com-key-trans_kem" id="sec-com-key-trans_kem">Composite Key Transport using Encryption and KEM primitives</a>
</h1>
<p id="rfc.section.3.p.1">This composite encryption mode is the generalization of the mode defined in <a href="#sec-com-key-trans_encr" class="xref">Section 2</a> to support a composite recipient public key which may contain a mixture of one or more encryption component algorithms with zero or more key encapsulation mechanism (KEM) component algorithms.</p>
<p id="rfc.section.3.p.2">This mode is compatible with protocols requiring a key transport primitive, such as CMS' KeyTransRecipientInfo <a href="#RFC5652" class="xref">[RFC5652]</a>.</p>
<p id="rfc.section.3.p.3">Security consideration: for a recipient composite public key to be applicable to this mode, all component KEMs MUST produce a shared secret whose bits are independent and uniformly distributed (aka "uniformly IID" or "uniformly random" or "full entropy") and therefore the shared secret is safe to use direcly as a symmetric key. If a recipient public key contains component KEMs which are not know to have this property, then implementors SHOULD use the more general mode described in <a href="#sec-com-key-exchange" class="xref">Section 4</a> which incorporates the use of a key derivation function. See <a href="#sec-consider-iid" class="xref">Section 7.1</a> for a further discussion of this security consideration.</p>
<p id="rfc.section.3.p.4">EDNOTE: also put this in the Security considerations section.</p>
<h1 id="rfc.section.3.1">
<a href="#rfc.section.3.1">3.1.</a> <a href="#algorithm-identifier-1" id="algorithm-identifier-1">Algorithm Identifier</a>
</h1>
<p id="rfc.section.3.1.p.1">The id-alg-composite-kem object identifier MUST be used to identify the usage of this mode</p>
<pre>
id-alg-composite-kem OBJECT IDENTIFIER ::= {
id-alg-composite-encryption OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
Algorithm(80) Composite(4) id-alg-composite-kem(5)}
</pre>
<p id="rfc.section.3.1.p.2">EDNOTE: this is a temporary OID for the purposes of prototyping. Permanent OIDs should be requested from IANA, see <a href="#sec-iana" class="xref">Section 6</a>.</p>
<h1 id="rfc.section.3.2">
<a href="#rfc.section.3.2">3.2.</a> <a href="#public-key-and-key-usage-1" id="public-key-and-key-usage-1">Public key and key usage</a>
</h1>
<p id="rfc.section.3.2.p.1">The recipient MUST have a composite public key which supports key transport or key encapsulation operations. Where the recipient public key has an associated keyUsage as specified in <a href="#RFC5280" class="xref">[RFC5280]</a>, it MUST have keyUsage: keyEncipherment. In other words, the mechanism specified in this section applies only if all of the recipient's public keys are encryption or KEM algorithms.</p>
<p id="rfc.section.3.2.p.2">In addition, for a recipient composite public key to be applicable to this mode, all component KEMs MUST be capable of producing a shared secret of SIZE bits, where SIZE is the length in bits of the content encryption key (CEK) to be transported. This is assumed for the remainder of this section.</p>
<h1 id="rfc.section.3.2.1">
<a href="#rfc.section.3.2.1">3.2.1.</a> <a href="#composite-or-1" id="composite-or-1">Composite-OR</a>
</h1>
<p id="rfc.section.3.2.1.p.1">The design intent of this mode is to support migration scenarios where a recipient has been provisioned with a composite key containing algorithms that its peers may not yet support. This mode allows the sender to encrypt for a subset of the recipient's public keys. Support for Composite OR subset encryption is indicated by the recipient at key generation time by marking its composite key with the id-composite-or-key algorithm identifier as defined in ~~~cite properly draft-ounsworth-pq-composite-keys~~~.</p>
<p id="rfc.section.3.2.1.p.2">Policy mechanisms defining allowed subets of algorithms could be applied here, but are out of scope of this document. As defined in this document, a recipient marking their public key as id-composite-or-key must accept the risk that a sender may encrypt sensitive data for it using any one of its component keys in isolation. Composite Or is a direct tradeoff of lower security for increased migration flexibility.</p>
<h1 id="rfc.section.3.3">
<a href="#rfc.section.3.3">3.3.</a> <a href="#sec-com-key-trans_kem-params" id="sec-com-key-trans_kem-params">Algorithm parameters</a>
</h1>
<p id="rfc.section.3.3.p.1">The composite key transport using encryption and KEM mode does not require additional parameters, and therefore any associated Params are ABSENT.</p>
<h1 id="rfc.section.3.4">
<a href="#rfc.section.3.4">3.4.</a> <a href="#encryption-process" id="encryption-process">Encryption process</a>
</h1>
<p id="rfc.section.3.4.p.1">Given these conditions are met, the encryption process defined in <a href="#sec-com-key-trans_encr_process" class="xref">Section 2.4</a> is modified as follows:</p>
<pre>
Input:
n The number of recipient component public keys
P1, P2, .., Pn Recipient component public keys
CEK The Content Encryption Key
SIZE The size of the Content Encryption Key in bits
Output:
E1, E2, .., En EncryptedKey values corresponding to each recipient
component public key
Intermediate values:
S1, S2, .., Sn One-time-pad secret keys to be encapsulated by each
component algorithm
Generation Procedure:
1. If recipient public key is of type id-composite-or-key, determine the
index of the last recipient public key to be encrypted for
i_last := index of last Pi to be encrypted for
Else,
i_last = n
2.
for i := 1 to n
a. if id-composite-or-key and Pi is to be skipped
Ei := emptyOctetString
continue to next i
b. If i == i_last
continue to next i
Else, if Pi is of type KEM:
Si,Ei := encaps(Pi)
CEK := CEK XOR Si
Else:
Si := random_bits(SIZE)
CEK := CEK XOR Si
Ei := encrypt(Si, Pi)
3. Encrypt the final CEK value
Ei_last = encrypt(CEK, Pi_last)
4. Output E1, E2, .., En
</pre>
<p id="rfc.section.3.4.p.2">Where <samp>random_bits(SIZE)</samp> is a cryptographically-secure random bit generator outputting SIZE bits, and where <samp>emptyOctetString</samp> is the octet string of length 0.</p>
<p id="rfc.section.3.4.p.3">If the sender does not support Composite Or encryption, this algorithm may be simplified by omitting step 1, 2a, and the if i == i_last statement in 2b.</p>
<p id="rfc.section.3.4.p.4">The design intent is that Composite Or encryption with a single recipient key collapses to being equivalent to direct encryption of the CEK.</p>
<h1 id="rfc.section.3.5">
<a href="#rfc.section.3.5">3.5.</a> <a href="#decryption-process" id="decryption-process">Decryption process</a>
</h1>
<p id="rfc.section.3.5.p.1">The decryption process defined in <a href="#sec-com-key-trans_decr_process" class="xref">Section 2.5</a> applies directly where <samp>decrypt()</samp> is substituted for <samp>decaps()</samp> when the underlying primitive is a KEM.</p>
<h1 id="rfc.section.4">
<a href="#rfc.section.4">4.</a> <a href="#sec-com-key-exchange" id="sec-com-key-exchange">Composite Key Exchange</a>
</h1>
<p id="rfc.section.4.p.1">This mode is the most general in that it supports a composite recipient public key which MAY contain an arbitrary mixture of encryption, key encapsulation mechanism (KEM), and key agreement component algorithms. Due to the nature of key agreement algorithms, this mode cannot take a content encryption key as input, but instead generates a master shared secret as an output. As such, the nomenclature in this mode differs from the modes above.</p>
<p id="rfc.section.4.p.2">This mode is compatible with protocols requiring a key agreement primitive, such as CMS' KeyAgreeRecipientInfo <a href="#RFC5652" class="xref">[RFC5652]</a>.</p>
<p id="rfc.section.4.p.3">Composite key exchange uses the underlying primitive to either encrypt for, encapsulate, or interactively do key agreement with each of the recipient's public keys, then all shared secrets are concatenated together and a KDF is applies as prescribed by NIST SP 800-56Cr2 <a href="#SP80056cr2" class="xref">[SP80056cr2]</a>.</p>
<h1 id="rfc.section.4.1">
<a href="#rfc.section.4.1">4.1.</a> <a href="#algorithm-identifier-2" id="algorithm-identifier-2">Algorithm Identifier</a>
</h1>
<p id="rfc.section.4.1.p.1">The id-alg-composite-keyex object identifier MUST be used to identify the usage of this mode</p>
<pre>
id-alg-composite-keyex OBJECT IDENTIFIER ::= {
id-alg-composite-encryption OBJECT IDENTIFIER ::= {
joint-iso-itu-t(2) country(16) us(840) organization(1) entrust(114027)
Algorithm(80) Composite(4) id-alg-composite-encryption(6) }
</pre>
<p id="rfc.section.4.1.p.2">EDNOTE: this is a temporary OID for the purposes of prototyping. Permanent OIDs should be requested from IANA, see <a href="#sec-iana" class="xref">Section 6</a>.</p>
<h1 id="rfc.section.4.2">
<a href="#rfc.section.4.2">4.2.</a> <a href="#public-key-and-key-usage-2" id="public-key-and-key-usage-2">Public key and key usage</a>
</h1>
<p id="rfc.section.4.2.p.1">The recipient MUST have a composite public key which supports key transport, key encapsulation, or key exchange operations. Where the recipient public key has an associated keyUsage as specified in <a href="#RFC5280" class="xref">[RFC5280]</a>, it MUST have keyUsage: keyEncipherment, keyAgreement. This mode is the most general and places the fewest restrictions on the recipient public key.</p>
<p id="rfc.section.4.2.p.2">EDNOTE: I think this violates our public key draft where we say that the public key's KU MUST apply to all components. ... we did not want mixing of signatures and encryption keys, but I think in this case we do want to allow mixing of keyEncipherment and keyExchange keys. Not sure how to fix that.</p>
<h1 id="rfc.section.4.2.1">
<a href="#rfc.section.4.2.1">4.2.1.</a> <a href="#composite-or-2" id="composite-or-2">Composite-OR</a>
</h1>
<p id="rfc.section.4.2.1.p.1">The design intent of this mode is to support migration scenarios where a recipient has been provisioned with a composite key containing algorithms that its peers may not yet support. This mode allows the sender to encrypt for a subset of the recipient's public keys. Support for Composite OR subset encryption is indicated by the recipient at key generation time by marking its composite key with the id-composite-or-key algorithm identifier as defined in ~~~cite properly draft-ounsworth-pq-composite-keys~~~.</p>
<p id="rfc.section.4.2.1.p.2">Policy mechanisms defining allowed subets of algorithms could be applied here, but are out of scope of this document. As defined in this document, a recipient marking their public key as id-composite-or-key must accept the risk that a sender may encrypt sensitive data for it using any one of its component keys in isolation. Composite Or is a direct tradeoff of lower security for increased migration flexibility.</p>
<h1 id="rfc.section.4.3">
<a href="#rfc.section.4.3">4.3.</a> <a href="#sec-com-key-exchange-params" id="sec-com-key-exchange-params">Algorithm parameters</a>
</h1>
<p id="rfc.section.4.3.p.1">The composite key exchange mode requires additional parameters to specify the KDF used to combine shared secrets into a master shared secret.</p>
<pre>
Params ::= KeyDerivationAlgorithmIdentifier
</pre>
<p id="rfc.section.4.3.p.2">The KeyDerivationAlgorithmIdentifier type is specified in <a href="#RFC5652" class="xref">[RFC5652]</a>. The KeyDerivationAlgorithmIdentifier definition is repeated here for completeness.</p>
<pre>
KeyDerivationAlgorithmIdentifier ::= AlgorithmIdentifier
</pre>
<h1 id="rfc.section.4.4">
<a href="#rfc.section.4.4">4.4.</a> <a href="#encapsulation-process" id="encapsulation-process">Encapsulation Process</a>
</h1>
<p id="rfc.section.4.4.p.1">Composite key exchange uses the underlying primitive to either encrypt for, encapsulate, or interactively do key agreement with each of the recipient's public keys, then all shared secrets are concatenated together and a KDF is applies as prescribed by NIST SP 800-56Cr2 <a href="#SP80056cr2" class="xref">[SP80056cr2]</a>.</p>
<pre>
Input:
P1, P2, .., Pn Public keys for the n component encryption
algorithms, a CompositePublicKey
SIZE The size, in bits, for shared secrets to be combined by both
parties into a content encryption key. This value SHOULD correspond
to the size of the content encryption key.
KDF A key derivation function
Output:
E1, E2, .., En EncryptedKey values corresponding to each recipient
component public key
M Master shared secret
Ciphertext and master secret Generation Procedure:
1. Generate a set of one-time-pad secret keys of
the same length as the content encryption key
for i := 1 to n
a. if id-composite-or-key and Pi is to be skipped
Si = emptyOctetString
Ei := emptyOctetString
continue to next i
b. if P1 is of type KEM or keyExchange:
Si,Ei := encaps(Pi)
else:
Si := random_bits(SIZE)
Ei := encrypt(Si, Pi)
2. Generate Z via concatenation
Z = S1 || S2 || .. || Sn
3. Generate the master shared secret via a KDF
M = KDF(Z)
4. Output M
Output E1, E2, .., En
</pre>
<p id="rfc.section.4.4.p.2">Where <samp>emptyOctetString</samp> is the octet string of length 0 that serves as a no-op or identity element for the concatenation in step 2.</p>
<p id="rfc.section.4.4.p.3">In cases where KDF is extensible output function, the length of M must be carried in the KeyDerivationAlgorithmIdentifier defined in <a href="#sec-com-key-exchange-params" class="xref">Section 4.3</a>.</p>
<p id="rfc.section.4.4.p.4">EDNOTE: It isn't clear to us how one uses the defined HKDF algorithmid (RFC 8619) here. Those OIDs specify a hash, but no output length or seed or info parameter either implicitely or explicitely. But we also don't see how it would be used with CMS either, for the same reason. ..?</p>
<p id="rfc.section.4.4.p.5">If the sender does not support Composite Or encryption, this algorithm may be simplified by omitting step 2a.</p>
<p id="rfc.section.4.4.p.6">EDNOTE: investigate whether step 3 really belongs here, or whether the surrounding protocol (ex. CMS EnvelopedData) will perform a final KDF anyways. We believe that outputting an IID master secret is consistent with modern KEM behaviour.</p>
<h1 id="rfc.section.4.5">
<a href="#rfc.section.4.5">4.5.</a> <a href="#decapsulation-process" id="decapsulation-process">Decapsulation Process</a>
</h1>
<pre>
Input:
n The number of recipient component public keys
SK1, SK2, .., SKn Recipient component secret keys
E1, E2, .., En EncryptedKey values corresponding to each recipient
component public key
KDF A key derivation function
Intermediate values:
S1, S2, .., Sn Shared secrets to be encapsulated by
each component algorithm
Output:
M Master shared secret
Master Secret Recovery Procedure:
1. Recover each shared secret
for i := 1 to n
if Ei == null
Si = EMPTY_STRING
Si := decrypt_or_decaps(Ei, SKi)
2. Generate Z via concatenation
Z = S1 || S2 || .. || Sn
3. Generate the master shared secret via a KDF
M = KDF(Z)
4. Output M
</pre>
<p id="rfc.section.4.5.p.1">"EMPTY_STRING" indicates a string or byte array of length zero so that that value as essentially omitted from the concatenation in step 2.</p>
<p id="rfc.section.4.5.p.2">The if statement in step 1 is the only modification required to support Composite Or encryption. The designers have intentionally omitted a check that the recipient key is of type id-composite-or-key because even if the sender erroneously used composite or subset for a recipient key which is not of type id-composite-or-key, the damage has already been done by generating a master secret and potentially transmitting data encrypted with it, no further harm can be done by decrypting it. However, where appropriate, clients SHOULD indicate a warning to users that this data was transmitted with weaker encrypting than their public key allows.</p>
<h1 id="rfc.section.5">
<a href="#rfc.section.5">5.</a> <a href="#sec-in-pract" id="sec-in-pract">In Practice</a>
</h1>
<p id="rfc.section.5.p.1">This section addresses practical issues of how this draft affects other protocols and standards.</p>
<h1 id="rfc.section.6">
<a href="#rfc.section.6">6.</a> <a href="#sec-iana" id="sec-iana">IANA Considerations</a>
</h1>
<p id="rfc.section.6.p.1">The following OIDs are to be assigned by IANA. The authors suggest that IANA assign OIDs for composite encryption on the id-pkix arc:</p>
<pre>
id-alg-composite OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) composite(??) id-alg-composite-encryption(??)}
</pre>
<pre>
id-alg-composite-kem OBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) composite(??) id-alg-composite-kem(??)}
</pre>
<pre>
id-alg-composite-keyex OBJECT IDENTIFIER ::= {
iOBJECT IDENTIFIER ::= {
iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) algorithms(6) composite(??) id-alg-composite-encryption(??)}
</pre>
<h1 id="rfc.section.7">
<a href="#rfc.section.7">7.</a> <a href="#security-considerations" id="security-considerations">Security Considerations</a>
</h1>
<h1 id="rfc.section.7.1">
<a href="#rfc.section.7.1">7.1.</a> <a href="#sec-consider-iid" id="sec-consider-iid">IID property of KEM primitives</a>
</h1>
<p id="rfc.section.7.1.p.1">Composite Key Transport using Encryption and KEM primitives defined in <a href="#sec-com-key-trans_kem" class="xref">Section 3</a> directly uses the shared secret output from the underlying KEM primitevas as a one-time-pad key to encrypt the CEK. Therefore the output of the KEM primitive of needs to meet the security properties of a one-time-pad key, namely that its bits are independent and identically distributed (IID). In particular, key agreement schemes such as ECDH or SIKE do not produce shared secrets that meet this requirement and therefore MUST use the fully general mechanism Composite Key Exchange defined in <a href="#sec-com-key-exchange" class="xref">Section 4</a>.</p>
<p id="rfc.section.7.1.p.2">EDNOTE: Should this be brough to CFRG to decide which KEMs are appropriate to use with this mechanism? It may be possible that we need to run the KEM output through a KDF; but we're trying to avoid needing to carry a KDF AlgID here.</p>
<h1 id="rfc.section.7.2">
<a href="#rfc.section.7.2">7.2.</a> <a href="#composite-or-modes" id="composite-or-modes">Composite-OR modes</a>
</h1>
<p id="rfc.section.7.2.p.1">Composite-OR eases migration at the expense of security. For composite encryption and key encapsulation, the weakening of security is entirely at the discretion of the sender, since once data has been encrypted and transmitted with weak ciphers, there is nothing the recipient can do to protect the data against record & decrypt attacks. Clients performing Composite Or encryption operations MUST ensure that the recipient's public key is of type id-composite-or-key before producing a ciphertext with a subset of the recipient's public keys.</p>
<p id="rfc.section.7.2.p.2">For some cases of composite key exchange, notably when the underlying key exchange primitive is used in a fully interactive (aka "ephemeral-ephemeral") mode, the sender cannot begin encrypting data until the recipient has completed the key exchange. The recipient SHOULD reject the connection if one or more null ciphertexts are encountered when the recipient's public key is not of type id-composite-or-key.</p>
<h1 id="rfc.section.7.3">
<a href="#rfc.section.7.3">7.3.</a> <a href="#policy-for-deprecated-or-unacceptable-algorithms" id="policy-for-deprecated-or-unacceptable-algorithms">Policy for Deprecated or Unacceptable Algorithms</a>
</h1>
<p id="rfc.section.7.3.p.1">Within the context of composite encryption, the sender holds the responsibility to ensure that chosen algorithms are of sufficient strength prior to encrypting and transmitting sensitive data under them. Composite is designed to provide security redundancy and to remain strong as long as at least one of the component algorithms remains strong.</p>
<p id="rfc.section.7.3.p.2">When encrypting for a Composite-OR public key and using a subset of the recipient's public key, then these redundancy guarantees no longer apply. The sender SHOULD employ a policy mechanism to ensure that they are using a combination of algorithms of sufficient strength. Even though this document does not define such a policy mechanism, but implementors making use of Composite-OR encryption are strongly encouraged to implement a policy mechanism.</p>
<h1 id="rfc.section.8">
<a href="#rfc.section.8">8.</a> <a href="#appendices" id="appendices">Appendices</a>
</h1>
<h1 id="rfc.section.8.1">
<a href="#rfc.section.8.1">8.1.</a> <a href="#asn1-module" id="asn1-module">ASN.1 Module</a>
</h1>
<p id="rfc.section.8.1.p.1">~~ TODO ~~</p>
<h1 id="rfc.section.8.2">
<a href="#rfc.section.8.2">8.2.</a> <a href="#intellectual-property-considerations" id="intellectual-property-considerations">Intellectual Property Considerations</a>
</h1>
<p id="rfc.section.8.2.p.1">The following IPR Disclosure relates to this draft:</p>
<p id="rfc.section.8.2.p.2">https://datatracker.ietf.org/ipr/3588/</p>
<p id="rfc.section.8.2.p.3">We are grateful to all, including any contributors who may have been inadvertently omitted from this list.</p>
<p id="rfc.section.8.2.p.4">This document borrows text from similar documents, including those referenced below. Thanks go to the authors of those documents. "Copying always makes things easier and less error prone" - <a href="#RFC8411" class="xref">[RFC8411]</a>.</p>
<h1 id="rfc.section.8.3">
<a href="#rfc.section.8.3">8.3.</a> <a href="#making-contributions" id="making-contributions">Making contributions</a>
</h1>