This repository has been archived by the owner on Jan 24, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-lamps-pkix-shake-current.xml
952 lines (858 loc) · 42.6 KB
/
draft-ietf-lamps-pkix-shake-current.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
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3279.xml">
<!-- <!ENTITY RFC3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml"> -->
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!-- <!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml"> -->
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY RFC5912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5912.xml">
<!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
<!ENTITY RFC8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8017.xml">
<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY I-D.draft-josefsson-pkix-eddsa SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-josefsson-pkix-eddsa-04.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-lamps-pkix-shake-11" ipr="trust200902" updates="3279">
<!-- category values: std, bcp, info, exp, and historic
ipr="full3978" (probably old)
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="SHAKE identifiers in X.509">Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Panos Kampanakis" initials="P.K."
surname="Kampanakis">
<organization>Cisco Systems</organization>
<address>
<email>pkampana@cisco.com</email>
</address>
</author>
<author fullname="Quynh Dang" initials="Q.D."
surname="Dang">
<organization>NIST</organization>
<address>
<postal>
<street>100 Bureau Drive, Stop 8930</street>
<city>Gaithersburg</city>
<region>MD</region>
<code>20899-8930</code>
<country>USA</country>
</postal>
<!-- <phone>+44 7889 488 335</phone> -->
<email>quynh.dang@nist.gov</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- <author fullname="Sean Turner" initials="S.T."
surname="Turner">
<organization>sn3rd</organization>
<address>
<postal>
<street></street>
<city>Soham</city>
<region></region>
<code></code>
<country>UK</country>
</postal>
<phone>+44 7889 488 335</phone>
<email>sean@sn3rd.com</email>
</address>
</author> -->
<date year="2019" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>LAMPS WG</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<!-- <keyword>template</keyword> -->
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the searPKIch engine. -->
<abstract>
<t>Digital signatures are used to sign messages, X.509
certificates and CRLs. This
document updates <xref target="RFC3279"/>
and describes the conventions for using the SHAKE function
family in Internet X.509 certificates and CRLs as one-way hash
functions with the RSA Probabilistic signature and
ECDSA signature algorithms. The conventions for the
associated subject public keys are also described.</t>
</abstract>
</front>
<middle>
<section title="Change Log">
<t>[ EDNOTE: Remove this section before publication. ]</t>
<t><list style="symbols">
<t>draft-ietf-lamps-pkix-shake-12:
<list>
<t>Nits identified by Roman, Eric V. Ben K., Barry L. in ballot position review.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-11:
<list>
<t>Nits identified by Roman in AD Review.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-10:
<list>
<t>Updated IANA considerations section to request for OID assignments. </t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-09:
<list>
<t>Fixed minor text nits.</t>
<t>Added text name allocation for SHAKEs in IANA considerations.</t>
<t>Updates in Sec Considerations section.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-08:
<list>
<t>Small nits from Russ while in WGLC.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-07:
<list>
<t>Incorporated Eric's suggestion from WGLC.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-06:
<list>
<t>Added informative references.</t>
<t>Updated ASN.1 so it compiles.</t>
<t>Updated IANA considerations.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-05:
<list>
<t>Added RFC8174 reference and text.</t>
<t>Explicitly explained why RSASSA-PSS-params are omitted in section 5.1.1.</t>
<t>Simplified Public Keys section by removing redundant info from RFCs.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-04:
<list>
<t>Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. </t>
<t>Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA.</t>
<t>Various ASN.1 fixes.</t>
<t>Text fixes.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-03:
<list>
<t>Updates based on suggestions and clarifications by Jim. </t>
<t>Added ASN.1.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-02:
<list>
<t>Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in PKIX.</t>
<t>Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, according the WG consensus.</t>
<t>Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage.</t>
<t>Removed the no longer used SHAKE OIDs from section 3.1.</t>
<t>Consolidated subsection for message digest algorithms.</t>
<t>Text fixes.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-01:
<list>
<t>Changed titles and section names.</t>
<t>Removed DSA after WG discussions.</t>
<t>Updated shake OID names and parameters, added MGF1 section.</t>
<t>Updated RSASSA-PSS section.</t>
<t>Added Public key algorithm OIDs.</t>
<t>Populated Introduction and IANA sections.</t>
</list></t>
<t>draft-ietf-lamps-pkix-shake-00:
<list>
<t>Initial version</t>
</list></t>
</list></t>
</section>
<section title="Introduction">
<t>This document defines cryptographic algorithm identifiers
for several cryptographic algorithms that use variable length output
SHAKE functions introduced in <xref target="SHA3"/> which can be used
with the Internet X.509 Certificate and Certificate Revocation List (CRL) profile <xref target="RFC5280"/>. </t>
<t>In the SHA-3 family, two extendable-output functions (SHAKEs),
SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256,
SHA3-384, and SHA3-512, are also defined but are out of scope for this document.
A SHAKE is a variable length hash function defined as SHAKE(M, d) where the
output is a d-bits-long digest of message M. The corresponding collision and second-preimage-resistance strengths for SHAKE128 are min(d/2,128) and min(d,128)
bits, respectively (Appendix A.1 <xref target="SHA3"/>).
And the corresponding collision and second-preimage-resistance strengths for SHAKE256
are min(d/2,256) and min(d,256) bits, respectively.</t>
<t>A SHAKE can be used as the message digest function (to hash the message to be signed)
in RSASSA-PSS <xref target="RFC8017"/> and ECDSA <xref target="X9.62"/>
and as the hash in the mask generation function (MGF) in RSASSA-PSS.
<!-- This specification describes the identifiers for SHAKEs to be used in X.509 and their
meaning.--> </t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<section anchor="terminology" title="Terminology">
<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="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
</section> <!-- Terminology -->
<?rfc needLines="8" ?>
<section title="Identifiers" anchor="oids">
<!-- Commention out the below OIDs as they are no longer pertinent for the below public keys and sigs -->
<!-- The Object Identifiers (OIDs) for these two hash functions are defined in
<xref target="shake-nist-oids"/> and are included here for convenience: </t>
<t><figure><artwork><![CDATA[
id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 17 }
ShakeOutputLen ::= INTEGER - - Output length in octets
]]></artwork></figure></t>
<t>When using the id-shake128-len algorithm identifier, the parameters
MUST be present, and they MUST employ the ShakeOutputLen -->
<!-- "MUST employ syntax borrowed from RFC4055 -->
<!-- syntax that contains an encoded positive integer value at least 32
in this specification.</t>
<t><figure><artwork><![CDATA[
id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
country(16) us(840) organization(1) gov(101) csor(3)
nistalgorithm(4) hashalgs(2) 18 }
ShakeOutputLen ::= INTEGER - - Output length in octets
]]></artwork></figure></t>
<t>When using the id-shake256-len algorithm identifier, the parameters
MUST be present, and they MUST employ the ShakeOutputLen -->
<!-- "MUST employ syntax borrowed from RFC4055 -->
<!-- syntax that contains an encoded positive integer value at least 64
in this specification.</t> -->
<t>This section defines four new object identifiers (OIDs), for RSASSA-PSS and ECDSA with each
of SHAKE128 and SHAKE256. The same algorithm identifiers can be
used for identifying a public key in RSASSA-PSS.</t>
<t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below.</t>
<t><figure><artwork><![CDATA[
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD1 }
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD2 }
]]></artwork></figure></t>
<t>The new algorithm identifiers of ECDSA signatures using SHAKEs are below.</t>
<t><list>
<t><figure><artwork><![CDATA[
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD3 }
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD4 }
]]></artwork></figure></t>
</list></t>
<!-- <xref target="RFC8017"/>, but we include it here as well for convenience:</t>
<t><figure><artwork><![CDATA[
id-mgf1 OBJECT IDENTIFIER ::= { pkcs-1 8 }
]]></artwork></figure>-->
<!-- <t>The parameters field associated with id-mgf1 MUST have a hashAlgorithm value that identifies
the hash used with MGF1. To use SHAKE as this hash, this parameter MUST be
id-shake128-len or id-shake256-len as specified in <xref target="xofs" /> above. </t>-->
<t>The parameters for the four identifiers above MUST be absent. That is,
the identifier SHALL be a SEQUENCE of one component, the OID.</t>
<t><xref target="rsa-sigs"/> and <xref target="ecdsa-sigs"/> specify the required output length
for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summary, when hashing messages
to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 bits respectively.
When the SHAKEs are used as mask generation functions RSASSA-PSS, their output length is
(8*ceil((n-1)/8) - 264) or (8*ceil((n-1)/8) - 520) bits, respectively, where n is the RSA modulus size in bits.</t>
</section>
<section title="Use in PKIX">
<section title="Signatures" anchor="sigs">
<t>Signatures are used in a number of different ASN.1 structures.
As shown in the ASN.1 representation from <xref target="RFC5280"/>
below, in an X.509 certificate, a signature is encoded with an
algorithm identifier in the signatureAlgorithm attribute and
a signatureValue attribute that contains the actual signature.
</t>
<t><figure><artwork><![CDATA[
Certificate ::= SEQUENCE {
tbsCertificate TBSCertificate,
signatureAlgorithm AlgorithmIdentifier,
signatureValue BIT STRING }
]]></artwork></figure></t>
<t>The identifiers defined in <xref target="oids"/> can be used
as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence
Certificate and the signature field in the sequence TBSCertificate in X.509
<xref target="RFC5280"/>.
The parameters of these signature algorithms are absent as explained
in <xref target="oids"/>.</t>
<t>Conforming CA implementations MUST specify the algorithms
explicitly by using the OIDs specified in <xref target="oids"/> when
encoding RSASSA-PSS or ECDSA with SHAKE signatures
in certificates and CRLs.
Conforming client implementations that process certificates and CRLs
using RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs.
Encoding rules for RSASSA-PSS and ECDSA
signature values are specified in <xref target="RFC4055"/> and
<xref target="RFC5480"/>, respectively.</t>
<t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA
curve order SHOULD be chosen in line with the SHAKE output length.
In the context of this document
SHAKE128 OIDs are RECOMMENDED for 2048 or 3072-bit RSA modulus or
curves with group order of 256-bits. SHAKE256 OIDs are RECOMMENDED for
4096-bit RSA modulus and higher or curves with group order of 384-bits
and higher.</t>
<section title="RSASSA-PSS Signatures" anchor="rsa-sigs">
<t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017"/>.
When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in <xref target="oids"/>
is used, the encoding MUST omit the parameters field. That is,
the AlgorithmIdentifier SHALL be a SEQUENCE of one component,
id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target="RFC4055"/>
defines RSASSA-PSS-params that are used to define the algorithms and inputs
to the algorithm. This specification does not use parameters because the
hash, mask generation algorithm, trailer and salt are embedded in
the OID definition.</t>
<t>The hash algorithm to hash a message being signed and the hash algorithm used as the
mask generation function <!-- "MGF(H, emLen - hLen - 1)" <xref target="RFC8017"/> -->
in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. The
output length of the hash algorithm which hashes the message SHALL be 32
(for SHAKE128) or 64 bytes (for SHAKE256). </t>
<t>The mask generation function takes an octet string of variable length and
a desired output length as input, and outputs an octet
string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be
used natively as the MGF function, instead of the MGF1 algorithm that uses
the hash function in multiple iterations as specified in Section B.2.1 of
<xref target="RFC8017"/>. In other words, the MGF is defined as
<!-- <t><figure><artwork><![CDATA[
SHAKE128(mgfSeed, maskLen)
]]></artwork></figure>
and
<figure><artwork><![CDATA[
SHAKE256(mgfSeed, maskLen)
]]></artwork></figure></t> -->
the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-SHAKE128 and
id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed
from which mask is generated, an octet string <xref target="RFC8017"/>.
As explained in Step 9 of section 9.1.1 of <xref target="RFC8017"/>, the output
length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message
length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and
64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively.
Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is
(8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048,
the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits
when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively. </t>
<t>The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128
or 64 bytes for id-RSASSA-PSS-SHAKE256.
Finally, the trailerField MUST be 1, which represents
the trailer field with hexadecimal value 0xBC <xref target="RFC8017"/>.</t>
<!-- <t><figure><artwork><![CDATA[
id-RSASSA-PSS OBJECT IDENTIFIER ::= { pkcs-1 k }
RSASSA-PSS-params ::= SEQUENCE {
hashAlgorithm HashAlgorithm,
maskGenAlgorithm MaskGenAlgorithm,
saltLength INTEGER,
trailerField INTEGER }
]]></artwork></figure></t> -->
<!-- <section title="EdDSA with SHAKE">
<t>[ EDNOTE: For the group to decide: pre-hash version or non-prehash version EdDSAs. PureEdDSA, the pre-hashed version of EdDSA, as currently also proposed in draft-ietf-curdle-cms-eddsa-signatures mandates the hash function as SHA512 for Ed25519 and SHAKE256(x,64) for Ed448. The HashEdDSA version of EdDSA does not define the hash. It is up to the WG to go the Pre-hash route which would require an OID that contained the hash. ] </t>
<t>
<list>
<t><figure><artwork><![CDATA[
id-eddsa-with-shake128 OBJECT IDENTIFIER ::= { }
]]></artwork></figure></t>
<t><figure><artwork><![CDATA[
id-eddsa-with-shake256 OBJECT IDENTIFIER ::= { }
]]></artwork></figure></t>
</list></t>
</section> -->
</section>
<section title="ECDSA Signatures" anchor="ecdsa-sigs">
<t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in
<xref target="X9.62"/>. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
(specified in <xref target="oids"/>) algorithm identifier appears, the respective SHAKE
function (SHAKE128 or SHAKE256) is used as the hash.
The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier
SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or
id-ecdsa-with-shake256.</t>
<t>For simplicity and compliance with the ECDSA standard specification,
the output length of the hash function must be explicitly determined. The
output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 256 or 512
bits, respectively. </t>
<t>Conforming CA implementations that generate ECDSA with SHAKE signatures
in certificates or CRLs SHOULD generate such signatures with a
deterministically generated, non-random k in accordance with all
the requirements specified in <xref target="RFC6979"/>.
<!-- Sections 7.2 and 7.3 of
<xref target="X9.62"/> or with all the requirements specified in Section
4.1.3 of <xref target="SEC1"/>. -->
They MAY also generate such signatures
in accordance with all other recommendations in <xref target="X9.62"/> or
<xref target="SEC1"/> if they have a stated policy that requires
conformance to those standards. Those standards have not specified
SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and
SHAKE256 with output length being 32 and 64 octets, respectively, can
be used instead of 256 and 512-bit output hash algorithms such as SHA256
and SHA512.</t>
<!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC6979"/>, HMAC is used to derive
the deterministic k. Conforming implementations that generate deterministic
ECDSA with SHAKE signatures in X.509 MUST use KMAC with SHAKE128 or KMAC with
SHAKE256 as specfied in <xref target="SP800-185"/> when SHAKE128 or SHAKE256 is
used as the message hashing algorithm, respectively. In this situation, KMAC with
SHAKE128 and KMAC with SHAKE256 have 256-bit and 512-bit outputs respectively,
and the optional customization bit string S is an empty string.</t> -->
</section>
</section>
<section title="Public Keys">
<t>Certificates conforming to <xref target="RFC5280"/> can convey a
public key for any public key algorithm. The certificate indicates
the public key algorithm through an algorithm identifier. This algorithm
identifier is an OID and optionally associated parameters.
The conventions and encoding for RSASSA-PSS and ECDSA <!-- and EdDSA -->
public keys algorithm identifiers are as specified in
Section 2.3.1 and 2.3.5 of <xref target="RFC3279"/>,
Section 3.1 of <xref target="RFC4055"/>
and Section 2.1 of <xref target="RFC5480"/>.
<!-- and <xref target="I-D.josefsson-pkix-eddsa"/>--></t>
<t>Traditionally, the rsaEncryption object identifier is used to
identify RSA public keys. The rsaEncryption object identifier
continues to identify the subject public key when the RSA private
key owner does not wish to limit the use of the public key
exclusively to RSASSA-PSS with SHAKEs. When the RSA private
key owner wishes to limit the use of the public key exclusively
to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for
RSASSA-PSS defined in <xref target="oids"/> SHOULD be used as the algorithm
field in the SubjectPublicKeyInfo sequence <xref target="RFC5280"/>.
Conforming client implementations that process RSASSA-PSS
with SHAKE public keys when processing certificates and CRLs MUST
recognize the corresponding OIDs. </t>
<t>Conforming CA implementations MUST specify the X.509 public key
algorithm explicitly by using the OIDs specified in <xref target="oids"/>
when encoding ECDSA with SHAKE public keys in certificates and CRLs.
Conforming client implementations that process ECDSA with
SHAKE public keys when processing certificates and CRLs MUST recognize
the corresponding OIDs. </t>
<t>The identifier parameters, as explained in <xref target="oids"/>,
MUST be absent.</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>One object identifier for the ASN.1 module in <xref target="asn"/>
is requested for the SMI Security for PKIX Module Identifiers
(1.3.6.1.5.5.7.0) registry: </t>
<texttable>
<ttcol align='center'>Decimal</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>References</ttcol>
<c>TBD</c>
<c>id-mod-pkix1-shakes-2019</c>
<c>[EDNOTE: THIS RFC]</c>
</texttable>
<t>IANA is requested to update the
SMI Security for PKIX Algorithms <xref target="SMI-PKIX"/>
(1.3.6.1.5.5.7.6) registry with four additional entries: </t>
<texttable>
<ttcol align='center'>Decimal</ttcol>
<ttcol align='center'>Description</ttcol>
<ttcol align='center'>References</ttcol>
<c>TBD1</c>
<c>id-RSASSA-PSS-SHAKE128</c>
<c>[EDNOTE: THIS RFC]</c>
<c>TBD2</c>
<c>id-RSASSA-PSS-SHAKE256</c>
<c>[EDNOTE: THIS RFC]</c>
<c>TBD3</c>
<c>id-ecdsa-with-shake128</c>
<c>[EDNOTE: THIS RFC]</c>
<c>TBD4</c>
<c>id-ecdsa-with-shake256</c>
<c>[EDNOTE: THIS RFC]</c>
</texttable>
<t>IANA is also requested to update the
Hash Function Textual Names Registry <xref target="Hash-Texts"/>
with two additional entries for SHAKE128
and SHAKE256: </t>
<texttable>
<ttcol align='center'>Hash Function Name</ttcol>
<ttcol align='center'>OID</ttcol>
<ttcol align='center'>Reference</ttcol>
<c>shake128</c>
<c>2.16.840.1.101.3.4.2.11</c>
<c>[EDNOTE: THIS RFC]</c>
<c>shake256</c>
<c>2.16.840.1.101.3.4.2.12</c>
<c>[EDNOTE: THIS RFC]</c>
</texttable>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document updates <xref target="RFC3279"/>. The security considerations
section of that document applies to this specification as well.</t>
<t>NIST has defined appropriate use of the hash functions in terms of the algorithm
strengths and expected time frames for secure use in Special Publications (SPs)
<xref target="SP800-78-4"/> and <xref target="SP800-107"/>.
These documents can be used as guides to choose appropriate key sizes
for various security scenarios. </t>
<!-- <t>The SHAKEs are deterministic functions. Like any other deterministic function,
executing multiple times with the same input will produce the
same output. Therefore, users should not expect unrelated outputs (with the
same or different output lengths) from running a SHAKE function with the
same input multiple times. The shorter of any two outputs produced from a
SHAKE with the same input is a prefix of the longer one. It is a similar
situation as truncating a 512-bit output of SHA-512 by taking its 256
left-most bits. These 256 left-most bits are a prefix of the 512-bit output.</t> -->
<!-- <t>Implementations must protect the signer's private key. Compromise of
the signer's private key permits masquerade attacks.</t> -->
<!-- <t>Implementations must randomly generate one-time values, such as the k value when generating a ECDSA
signature. In addition, the generation of public/private key pairs
relies on random numbers. The use of inadequate pseudo-random
number generators (PRNGs) to generate such cryptographic values can
result in little or no security. The generation of quality random
numbers is difficult. <xref target="RFC4086"/> offers important guidance
in this area, and <xref target="SP800-90A"/> series provide acceptable
PRNGs.</t> -->
<!-- <t>Implementers should be aware that cryptographic algorithms may
become weaker with time. As new cryptanalysis techniques are developed
and computing power increases, the work factor or time required to break a
particular cryptographic algorithm may decrease. Therefore, cryptographic
algorithm implementations should be modular allowing new algorithms
to be readily inserted. That is, implementers should be prepared to
regularly update the set of algorithms in their implementations.</t> -->
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="Acknowledgements" title="Acknowledgements">
<t>We would like to thank Sean Turner, Jim Schaad and Eric
Rescorla for their valuable contributions to this document.</t>
<t>The authors would like to thank Russ Housley for his guidance and
very valuable contributions with the ASN.1 module.</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
&RFC3279;
&RFC8174;
<!-- &RFC3280; -->
&RFC4055;
&RFC5280;
&RFC5480;
&RFC8017; <!-- RFC8017 is Informational draft but we are keeping it in the Normative References even though idnits complains because we need a normative reference for RSASSA-PSS. RFC4056 does the same thing with RSASS-PSS v2.1 -->
<!-- <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-josefsson-pkix-eddsa-04.xml"?> -->
<reference anchor="SHA3" target="https://www.nist.gov/publications/sha-3-standard-permutation-based-hash-and-extendable-output-functions">
<front>
<title>SHA-3 Standard - Permutation-Based Hash and Extendable-Output Functions FIPS PUB 202</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date month="August" year="2015" />
</front>
</reference>
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
<!--&RFC2629; -->
&RFC5912;
&RFC6979;
<!-- &RFC4086; -->
<!--<reference anchor="shake-nist-oids" target="https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration">
<front>
<title>Computer Security Objects Register</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="October" year="2017" />
</front>
</reference> -->
<reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date month="May" year="2009" />
</front>
</reference>
<reference anchor="X9.62">
<front>
<title>X9.62-2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)</title>
<author>
<organization>American National Standard for Financial Services (ANSI)</organization>
</author>
<date month="November" year="2005" />
</front>
</reference>
<reference anchor="SP800-78-4" target="https://csrc.nist.gov/csrc/media/publications/sp/800-78/4/final/documents/sp800_78-4_revised_draft.pdf">
<front>
<title>SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal Identity Verification</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date month="May" year="2014" />
</front>
</reference>
<reference anchor="SMI-PKIX" target="https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.6">
<front>
<title>SMI Security for PKIX Algorithms</title>
<author>
<organization>IANA</organization>
</author>
<date month="March" year="2019" />
</front>
</reference>
<reference anchor="Hash-Texts" target="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml">
<front>
<title>Hash Function Textual Names</title>
<author>
<organization>IANA</organization>
</author>
<date month="July" year="2017" />
</front>
</reference>
<reference anchor="SP800-107" target="https://csrc.nist.gov/csrc/media/publications/sp/800-107/rev-1/final/documents/draft_revised_sp800-107.pdf">
<front>
<title>SP800-107: Recommendation for Applications Using Approved Hash Algorithms</title>
<author>
<organization>National Institute of Standards and Technology (NIST)</organization>
</author>
<date month="May" year="2014" />
</front>
</reference>
<!-- <reference anchor="SP800-90A" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
<front>
<title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90A</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="June" year="2015" />
</front>
</reference> -->
<!-- <reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
<front>
<title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. NIST SP 800-185</title>
<author>
<organization>National Institute of Standards and Technology</organization>
</author>
<date month="December" year="2016" />
</front>
</reference> -->
</references>
<section anchor="asn" title="ASN.1 module">
<t>This appendix includes the ASN.1 module for SHAKEs in X.509.
This module does not come from any existing RFC. </t>
<t><figure><artwork><![CDATA[
PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-shakes-2019(TBD) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
-- EXPORTS ALL;
IMPORTS
-- FROM [RFC5912]
PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
FROM AlgorithmInformation-2009
{ iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
-- FROM [RFC5912]
RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,
CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value
FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-algorithms2008-02(56) }
;
--
-- Message Digest Algorithms (mda-)
--
DigestAlgorithms DIGEST-ALGORITHM ::= {
-- This expands DigestAlgorithms from [RFC5912]
mda-shake128 |
mda-shake256,
...
}
--
-- One-Way Hash Functions
--
-- SHAKE128
mda-shake128 DIGEST-ALGORITHM ::= {
IDENTIFIER id-shake128 -- with output length 32 bytes.
}
id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4)
hashAlgs(2) 11 }
-- SHAKE256
mda-shake256 DIGEST-ALGORITHM ::= {
IDENTIFIER id-shake256 -- with output length 64 bytes.
}
id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
us(840) organization(1) gov(101)
csor(3) nistAlgorithm(4)
hashAlgs(2) 12 }
--
-- Public Key (pk-) Algorithms
--
PublicKeys PUBLIC-KEY ::= {
-- This expands PublicKeys from [RFC5912]
pk-rsaSSA-PSS-SHAKE128 |
pk-rsaSSA-PSS-SHAKE256,
...
}
-- The hashAlgorithm is mda-shake128
-- The maskGenAlgorithm is id-shake128
-- Mask Gen Algorithm is SHAKE128 with output length
-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
-- modulus in bits.
-- The saltLength is 32. The trailerField is 1.
pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= {
IDENTIFIER id-RSASSA-PSS-SHAKE128
KEY RSAPublicKey
PARAMS ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE { nonRepudiation, digitalSignature,
keyCertSign, cRLSign }
}
-- The hashAlgorithm is mda-shake256
-- The maskGenAlgorithm is id-shake256
-- Mask Gen Algorithm is SHAKE256 with output length
-- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA
-- modulus in bits.
-- The saltLength is 64. The trailerField is 1.
pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= {
IDENTIFIER id-RSASSA-PSS-SHAKE256
KEY RSAPublicKey
PARAMS ARE absent
-- Private key format not in this module --
CERT-KEY-USAGE { nonRepudiation, digitalSignature,
keyCertSign, cRLSign }
}
--
-- Signature Algorithms (sa-)
--
SignatureAlgs SIGNATURE-ALGORITHM ::= {
-- This expands SignatureAlgorithms from [RFC5912]
sa-rsassapssWithSHAKE128 |
sa-rsassapssWithSHAKE256 |
sa-ecdsaWithSHAKE128 |
sa-ecdsaWithSHAKE256,
...
}
--
-- SMIME Capabilities (sa-)
--
SMimeCaps SMIME-CAPS ::= {
-- The expands SMimeCaps from [RFC5912]
sa-rsassapssWithSHAKE128.&smimeCaps |
sa-rsassapssWithSHAKE256.&smimeCaps |
sa-ecdsaWithSHAKE128.&smimeCaps |
sa-ecdsaWithSHAKE256.&smimeCaps,
...
}
-- RSASSA-PSS with SHAKE128
sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-RSASSA-PSS-SHAKE128
PARAMS ARE absent
-- The hashAlgorithm is mda-shake128
-- The maskGenAlgorithm is id-shake128
-- Mask Gen Algorithm is SHAKE128 with output length
-- (8*ceil((n-1)/8) - 264) bits, where n is the RSA
-- modulus in bits.
-- The saltLength is 32. The trailerField is 1
HASHES { mda-shake128 }
PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 }
SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
}
id-RSASSA-PSS-SHAKE128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD1 }
-- RSASSA-PSS with SHAKE256
sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-RSASSA-PSS-SHAKE256
PARAMS ARE absent
-- The hashAlgorithm is mda-shake256
-- The maskGenAlgorithm is id-shake256
-- Mask Gen Algorithm is SHAKE256 with output length
-- (8*ceil((n-1)/8) - 520)-bits, where n is the
-- RSA modulus in bits.
-- The saltLength is 64. The trailerField is 1.
HASHES { mda-shake256 }
PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 }
SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
}
id-RSASSA-PSS-SHAKE256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD2 }
-- ECDSA with SHAKE128
sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-ecdsa-with-shake128
VALUE ECDSA-Sig-Value
PARAMS ARE absent
HASHES { mda-shake128 }
PUBLIC-KEYS { pk-ec }
SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
}
id-ecdsa-with-shake128 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD3 }
-- ECDSA with SHAKE256
sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
IDENTIFIER id-ecdsa-with-shake256
VALUE ECDSA-Sig-Value
PARAMS ARE absent
HASHES { mda-shake256 }
PUBLIC-KEYS { pk-ec }
SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
}
id-ecdsa-with-shake256 OBJECT IDENTIFIER ::= { iso(1)
identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) algorithms(6)
TBD4 }
END
]]></artwork></figure>
</t>
</section>
</back>
</rfc>