1<?xml version='1.0' encoding='utf-8'?>
2<!-- This template is for creating an Internet Draft using xml2rfc,
3     which is available here: http://xml.resource.org. -->
4<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent" [
5<!-- One method to get references from the online citation libraries.
6     There has to be one entity for each item to be referenced. 
7     An alternate method (rfc include) is described in the references. --><!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
8<!ENTITY RFC3279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3279.xml">
9<!-- <!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">
10<!-- <!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">
11<!ENTITY RFC5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml">
12<!ENTITY RFC5912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5912.xml">
13<!ENTITY RFC6979 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6979.xml">
14<!ENTITY RFC8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8017.xml">
15<!ENTITY RFC8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
16<!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">
17]>
18<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
19<!-- used by XSLT processors -->
20<!-- For a complete list and description of processing instructions (PIs), 
21     please see http://xml.resource.org/authoring/README.html. -->
22<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
23     (Here they are set differently than their defaults in xml2rfc v1.32) -->
24<?rfc strict="yes" ?>
25<!-- give errors regarding ID-nits and DTD validation -->
26<!-- control the table of contents (ToC) -->
27<?rfc toc="yes"?>
28<!-- generate a ToC -->
29<?rfc tocdepth="4"?>
30<!-- the number of levels of subsections in ToC. default: 3 -->
31<!-- control references -->
32<?rfc symrefs="yes"?>
33<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
34<?rfc sortrefs="yes" ?>
35<!-- sort the reference entries alphabetically -->
36<!-- control vertical white space 
37     (using these PIs as follows is recommended by the RFC Editor) -->
38<?rfc compact="yes" ?>
39<!-- do not start each main section on a new page -->
40<?rfc subcompact="no" ?>
41<!-- keep one blank line between list items -->
42<!-- end of list of popular I-D processing instructions -->
43<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-lamps-pkix-shake-15" ipr="trust200902" updates="3279" obsoletes="" submissionType="IETF" xml:lang="en" version="3">
44  <!-- xml2rfc v2v3 conversion 2.23.1 -->
45  <!-- category values: std, bcp, info, exp, and historic
46     ipr="full3978" (probably old)
47     ipr values: full3667, noModification3667, noDerivatives3667
48     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
49     they will automatically be output with "(if approved)" -->
50  <!-- ***** FRONT MATTER ***** -->
51  <front>
52    <!-- The abbreviated title is used in the page header - it is only necessary if the 
53         full title is longer than 39 characters -->
54    <title abbrev="SHAKE identifiers in X.509">Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs</title>
55    <seriesInfo name="Internet-Draft" value="draft-ietf-lamps-pkix-shake-15"/>
56    <!-- add 'role="editor"' below for the editors if appropriate -->
57    <author fullname="Panos Kampanakis" initials="P.K." surname="Kampanakis">
58      <organization>Cisco Systems</organization>
59      <address>
60        <email>pkampana@cisco.com</email>
61      </address>
62    </author>
63    <author fullname="Quynh Dang" initials="Q.D." surname="Dang">
64      <organization>NIST</organization>
65      <address>
66        <postal>
67          <street>100 Bureau Drive, Stop 8930</street>
68          <city>Gaithersburg</city>
69          <region>MD</region>
70          <code>20899-8930</code>
71          <country>USA</country>
72        </postal>
73        <!-- <phone>+44 7889 488 335</phone> -->
74        <email>quynh.dang@nist.gov</email>
75        <!-- uri and facsimile elements may also be added -->
76      </address>
77    </author>
78    <!-- <author fullname="Sean Turner" initials="S.T."
79            surname="Turner">
80      <organization>sn3rd</organization>
81      <address>
82        <postal>
83          <street></street>
84          <city>Soham</city>
85          <region></region>
86          <code></code>
87          <country>UK</country>
88        </postal>
89        <phone>+44 7889 488 335</phone>
90        <email>sean@sn3rd.com</email> 
91      </address>
92    </author> -->
93    <date year="2019"/>
94    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
95         in the current day for you. If only the current year is specified, xml2rfc will fill 
96  in the current day and month for you. If the year is not the current one, it is 
97  necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
98  purpose of calculating the expiry date).  With drafts it is normally sufficient to 
99  specify just the year. -->
100    <!-- Meta-data Declarations -->
101    <area>General</area>
102    <workgroup>LAMPS WG</workgroup>
103    <!-- WG name at the upperleft corner of the doc,
104         IETF is fine for individual submissions.  
105  If this element is not present, the default is "Network Working Group",
106         which is used by the RFC Editor as a nod to the history of the IETF. -->
107    <!-- <keyword>template</keyword> -->
108    <!-- Keywords will be incorporated into HTML output
109         files in a meta tag but they have no effect on text or nroff
110         output. If you submit your draft to the RFC Editor, the
111         keywords will be used for the searPKIch engine. -->
112    <abstract>
113      <t>Digital signatures are used to sign messages, X.509 
114   certificates and CRLs. This document updates the 
115   "Algorithms and Identifiers for the Internet 
116   X.509 Public Key Infrastructure Certificate and 
117   Certificate Revocation List Profile" (RFC3279)
118   and describes the conventions for using the SHAKE function 
119   family in Internet X.509 certificates and revocation lists 
120   as one-way hash functions with the RSA Probabilistic signature 
121   and ECDSA signature algorithms. The conventions for the 
122   associated subject public keys are also described.</t>
123    </abstract>
124  </front>
125  <middle>
126    <section numbered="true" toc="default">
127      <name>Change Log</name>
128      <t>[ EDNOTE: Remove this section before publication. ]</t>
129      <ul spacing="normal">
130        <li>
131          <t>draft-ietf-lamps-pkix-shake-15:
132          </t>
133          <ul spacing="normal">
134            <li>Minor editorial nits.</li>
135          </ul>
136        </li>
137        <li>
138          <t>draft-ietf-lamps-pkix-shake-14:
139          </t>
140          <ul spacing="normal">
141            <li>Fixing error with incorrect preimage resistance bits for SHA128 and SHA256.</li>
142          </ul>
143        </li>
144        <li>
145          <t>draft-ietf-lamps-pkix-shake-13:
146          </t>
147          <ul spacing="normal">
148            <li>Addressing one applicable comment from Dan M. about sec levels while in secdir review of draft-ietf-lamps-cms-shakes.</li>
149            <li>Addressing comment from Scott B.'s opsdir review about references in the abstract.</li>
150          </ul>
151        </li>
152        <li>
153          <t>draft-ietf-lamps-pkix-shake-12:
154          </t>
155          <ul spacing="normal">
156            <li>Nits identified by Roman, Eric V. Ben K., Barry L. in ballot position review.</li>
157          </ul>
158        </li>
159        <li>
160          <t>draft-ietf-lamps-pkix-shake-11:
161          </t>
162          <ul spacing="normal">
163            <li>Nits identified by Roman in AD Review.</li>
164          </ul>
165        </li>
166        <li>
167          <t>draft-ietf-lamps-pkix-shake-10:
168          </t>
169          <ul spacing="normal">
170            <li>Updated IANA considerations section to request for OID assignments. </li>
171          </ul>
172        </li>
173        <li>
174          <t>draft-ietf-lamps-pkix-shake-09:
175          </t>
176          <ul spacing="normal">
177            <li>Fixed minor text nits.</li>
178            <li>Added text name allocation for SHAKEs in IANA considerations.</li>
179            <li>Updates in Sec Considerations section.</li>
180          </ul>
181        </li>
182        <li>
183          <t>draft-ietf-lamps-pkix-shake-08:
184          </t>
185          <ul spacing="normal">
186            <li>Small nits from Russ while in WGLC.</li>
187          </ul>
188        </li>
189        <li>
190          <t>draft-ietf-lamps-pkix-shake-07:
191          </t>
192          <ul spacing="normal">
193            <li>Incorporated Eric's suggestion from WGLC.</li>
194          </ul>
195        </li>
196        <li>
197          <t>draft-ietf-lamps-pkix-shake-06:
198          </t>
199          <ul spacing="normal">
200            <li>Added informative references.</li>
201            <li>Updated ASN.1 so it compiles.</li>
202            <li>Updated IANA considerations.</li>
203          </ul>
204        </li>
205        <li>
206          <t>draft-ietf-lamps-pkix-shake-05:
207          </t>
208          <ul spacing="normal">
209            <li>Added RFC8174 reference and text.</li>
210            <li>Explicitly explained why RSASSA-PSS-params are omitted in section 5.1.1.</li>
211            <li>Simplified Public Keys section by removing redundant info from RFCs.</li>
212          </ul>
213        </li>
214        <li>
215          <t>draft-ietf-lamps-pkix-shake-04:
216          </t>
217          <ul spacing="normal">
218            <li>Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. </li>
219            <li>Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA.</li>
220            <li>Various ASN.1 fixes.</li>
221            <li>Text fixes.</li>
222          </ul>
223        </li>
224        <li>
225          <t>draft-ietf-lamps-pkix-shake-03:
226          </t>
227          <ul spacing="normal">
228            <li>Updates based on suggestions and clarifications by Jim. </li>
229            <li>Added ASN.1.</li>
230          </ul>
231        </li>
232        <li>
233          <t>draft-ietf-lamps-pkix-shake-02:
234          </t>
235          <ul spacing="normal">
236            <li>Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in PKIX.</li>
237            <li>Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, according the WG consensus.</li>
238            <li>Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage.</li>
239            <li>Removed the no longer used SHAKE OIDs from section 3.1.</li>
240            <li>Consolidated subsection for message digest algorithms.</li>
241            <li>Text fixes.</li>
242          </ul>
243        </li>
244        <li>
245          <t>draft-ietf-lamps-pkix-shake-01:
246          </t>
247          <ul spacing="normal">
248            <li>Changed titles and section names.</li>
249            <li>Removed DSA after WG discussions.</li>
250            <li>Updated shake OID names and parameters, added MGF1 section.</li>
251            <li>Updated RSASSA-PSS section.</li>
252            <li>Added Public key algorithm OIDs.</li>
253            <li>Populated Introduction and IANA sections.</li>
254          </ul>
255        </li>
256        <li>
257          <t>draft-ietf-lamps-pkix-shake-00:
258          </t>
259          <ul spacing="normal">
260            <li>Initial version</li>
261          </ul>
262        </li>
263      </ul>
264    </section>
265    <section numbered="true" toc="default">
266      <name>Introduction</name>
267      <t><xref target="RFC3279" format="default"/> defines cryptographic algorithm 
268   identifiers for the Internet X.509 Certificate and Certificate Revocation 
269   Lists (CRL) profile <xref target="RFC5280" format="default"/>. This document updates RFC3279 
270   and defines identifiers for several cryptographic algorithms that use 
271   variable length output SHAKE functions introduced in <xref target="SHA3" format="default"/> 
272   which can be used with . </t>
273      <t>In the SHA-3 family, two extendable-output functions (SHAKEs),  
274   SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256, 
275   SHA3-384, and SHA3-512, are also defined but are out of scope for this document. 
276   A SHAKE is a variable length hash function defined as SHAKE(M, d) where the 
277   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) 
278   bits, respectively (Appendix A.1 <xref target="SHA3" format="default"/>). 
279   And the corresponding collision and second-preimage-resistance strengths for SHAKE256 
280   are min(d/2,256) and min(d,256) bits, respectively.</t>
281      <t>A SHAKE can be used as the message digest function (to hash the message to be signed) 
282   in RSASSA-PSS <xref target="RFC8017" format="default"/> and ECDSA <xref target="X9.62" format="default"/> 
283      and as the hash in the mask generation function (MGF) in RSASSA-PSS. 
284   <!-- This specification describes the identifiers for SHAKEs to be used in X.509 and their 
285   meaning.--> </t>
286    </section>
287    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
288    <section anchor="terminology" numbered="true" toc="default">
289      <name>Terminology</name>
290      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
291      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
292      "MAY", and "OPTIONAL" in this document are to be interpreted as
293      described in BCP 14 <xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default"/> 
294      when, and only when, they appear in all capitals, as shown here.</t>
295    </section>
296    <!-- Terminology -->
297    <section anchor="oids" numbered="true" toc="default">
298      <name>Identifiers</name>
299      <!-- Commention out the below OIDs as they are no longer pertinent for the below public keys and sigs -->
300      <!-- The Object Identifiers (OIDs) for these two hash functions are defined in 
301   <xref target="shake-nist-oids"/> and are included here for convenience: </t>
302      
303   <t><figure><artwork><![CDATA[
304  id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
305 country(16) us(840) organization(1) gov(101) csor(3)
306 nistalgorithm(4) hashalgs(2) 17 } 
307
308  ShakeOutputLen ::= INTEGER - - Output length in octets
309]]></artwork></figure></t>
310   <t>When using the id-shake128-len algorithm identifier, the parameters 
311   MUST be present, and they MUST employ the ShakeOutputLen -->
312      <!-- "MUST employ syntax borrowed from RFC4055 -->
313      <!-- syntax that contains an encoded positive integer value at least 32  
314   in this specification.</t>
315   <t><figure><artwork><![CDATA[
316  id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
317 country(16) us(840) organization(1) gov(101) csor(3)
318 nistalgorithm(4) hashalgs(2) 18 }   
319
320  ShakeOutputLen ::= INTEGER - - Output length in octets
321]]></artwork></figure></t>
322   <t>When using the id-shake256-len algorithm identifier, the parameters 
323   MUST be present, and they MUST employ the ShakeOutputLen -->
324      <!-- "MUST employ syntax borrowed from RFC4055 -->
325      <!-- syntax that contains an encoded positive integer value at least 64 
326   in this specification.</t> -->
327      <t>This section defines four new object identifiers (OIDs), for RSASSA-PSS and ECDSA with each 
328   of SHAKE128 and SHAKE256. The same algorithm identifiers can be  
329   used for identifying a public key in RSASSA-PSS.</t>
330      <t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below.</t>
331      <artwork name="" type="" align="left" alt=""><![CDATA[
332  id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1) 
333            identified-organization(3) dod(6) internet(1) 
334            security(5) mechanisms(5) pkix(7) algorithms(6)
335            TBD1 }
336
337  id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1) 
338            identified-organization(3) dod(6) internet(1) 
339            security(5) mechanisms(5) pkix(7) algorithms(6)
340            TBD2 }
341]]></artwork>
342      <t>The new algorithm identifiers of ECDSA signatures using SHAKEs are below.</t>
343      <ul empty="true" spacing="normal">
344        <li>
345          <artwork name="" type="" align="left" alt=""><![CDATA[
346  id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1) 
347            identified-organization(3) dod(6) internet(1) 
348            security(5) mechanisms(5) pkix(7) algorithms(6)
349            TBD3 }            
350
351  id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1) 
352            identified-organization(3) dod(6) internet(1) 
353            security(5) mechanisms(5) pkix(7) algorithms(6)
354            TBD4 }
355]]></artwork>
356        </li>
357      </ul>
358      <!-- <xref target="RFC8017"/>, but we include it here as well for convenience:</t>
359   <t><figure><artwork><![CDATA[
360   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }
361]]></artwork></figure>-->
362      <!-- <t>The parameters field associated with id-mgf1 MUST have a hashAlgorithm value that identifies 
363   the hash used with MGF1. To use SHAKE as this hash, this parameter MUST be 
364   id-shake128-len or id-shake256-len as specified in <xref target="xofs" /> above. </t>-->
365      <t>The parameters for the four identifiers above MUST be absent. That is, 
366   the identifier SHALL be a SEQUENCE of one component, the OID.</t>
367      <t><xref target="rsa-sigs" format="default"/> and <xref target="ecdsa-sigs" format="default"/> specify the required output length 
368   for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summary, when hashing messages
369      to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 bits respectively. 
370   When the SHAKEs are used as mask generation functions RSASSA-PSS, their output length is 
371   (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>
372    </section>
373    <section numbered="true" toc="default">
374      <name>Use in PKIX</name>
375      <section anchor="sigs" numbered="true" toc="default">
376        <name>Signatures</name>
377        <t>Signatures are used in a number of different ASN.1 structures.
378        As shown in the ASN.1 representation from <xref target="RFC5280" format="default"/> 
379 below, in an X.509 certificate, a signature is encoded with an 
380 algorithm identifier in the signatureAlgorithm attribute and 
381 a signatureValue attribute that contains the actual signature.  
382        </t>
383        <artwork name="" type="" align="left" alt=""><![CDATA[
384   Certificate  ::=  SEQUENCE  {
385      tbsCertificate       TBSCertificate,
386      signatureAlgorithm   AlgorithmIdentifier,
387      signatureValue       BIT STRING  }
388]]></artwork>
389        <t>The identifiers defined in <xref target="oids" format="default"/> can be used 
390 as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence 
391 Certificate and the signature field in the sequence TBSCertificate in X.509  
392 <xref target="RFC5280" format="default"/>. 
393 The parameters of these signature algorithms are absent as explained 
394 in <xref target="oids" format="default"/>.</t>
395        <t>Conforming CA implementations MUST specify the algorithms  
396 explicitly by using the OIDs specified in <xref target="oids" format="default"/> when 
397 encoding RSASSA-PSS or ECDSA with SHAKE signatures 
398 in certificates and CRLs.
399 Conforming client implementations that process certificates and CRLs 
400 using RSASSA-PSS or ECDSA with SHAKE MUST recognize the corresponding OIDs.
401 Encoding rules for RSASSA-PSS and ECDSA 
402 signature values are specified in <xref target="RFC4055" format="default"/> and 
403 <xref target="RFC5480" format="default"/>, respectively.</t>
404        <t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA 
405 curve order SHOULD be chosen in line with the SHAKE output length. 
406 Refer to <xref target="Security" format="default"/> for more details.</t>
407        <section anchor="rsa-sigs" numbered="true" toc="default">
408          <name>RSASSA-PSS Signatures</name>
409          <t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017" format="default"/>. 
410   When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in <xref target="oids" format="default"/> 
411   is used, the encoding MUST omit the parameters field. That is, 
412   the AlgorithmIdentifier SHALL be a SEQUENCE of one component,  
413   id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target="RFC4055" format="default"/>
414   defines RSASSA-PSS-params that are used to define the algorithms and inputs 
415   to the algorithm. This specification does not use parameters because the 
416   hash, mask generation algorithm, trailer and salt are embedded in 
417   the OID definition.</t>
418          <t>The hash algorithm to hash a message being signed and the hash algorithm used as the
419   mask generation function <!-- "MGF(H, emLen - hLen - 1)" <xref target="RFC8017"/> -->
420   in RSASSA-PSS MUST be the same: both SHAKE128 or both SHAKE256. The 
421   output length of the hash algorithm which hashes the message SHALL be 32 
422   (for SHAKE128) or 64 bytes (for SHAKE256). </t>
423          <t>The mask generation function takes an octet string of variable length and
424   a desired output length as input, and outputs an octet 
425   string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs MUST be 
426   used natively as the MGF function, instead of the MGF1 algorithm that uses 
427   the hash function in multiple iterations as specified in Section B.2.1 of 
428   <xref target="RFC8017" format="default"/>. In other words, the MGF is defined as 
429   <!-- <t><figure><artwork><![CDATA[
430    SHAKE128(mgfSeed, maskLen) 
431]]></artwork></figure>
432          and 
433          <figure><artwork><![CDATA[
434    SHAKE256(mgfSeed, maskLen)
435]]></artwork></figure></t> --> 
436          the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-SHAKE128 and 
437   id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed 
438   from which mask is generated, an octet string <xref target="RFC8017" format="default"/>.   
439   As explained in Step 9 of section 9.1.1 of <xref target="RFC8017" format="default"/>, the output 
440   length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 
441   length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 
442   64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. 
443   Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is 
444   (8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048, 
445   the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits 
446   when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively. </t>
447          <t>The RSASSA-PSS saltLength MUST be 32 bytes for id-RSASSA-PSS-SHAKE128 
448   or 64 bytes for id-RSASSA-PSS-SHAKE256. 
449   Finally, the trailerField MUST be 1, which represents 
450   the trailer field with hexadecimal value 0xBC <xref target="RFC8017" format="default"/>.</t>
451          <!-- <t><figure><artwork><![CDATA[
452   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 k }
453
454   RSASSA-PSS-params  ::=  SEQUENCE  {
455         hashAlgorithm      HashAlgorithm, 
456         maskGenAlgorithm   MaskGenAlgorithm, 
457         saltLength         INTEGER, 
458         trailerField       INTEGER }
459]]></artwork></figure></t> -->
460          <!-- <section title="EdDSA with SHAKE">
461          <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>
462   <t>
463      <list>
464    <t><figure><artwork><![CDATA[
465id-eddsa-with-shake128 OBJECT IDENTIFIER ::= { }
466]]></artwork></figure></t>
467    <t><figure><artwork><![CDATA[
468id-eddsa-with-shake256 OBJECT IDENTIFIER ::= {  }
469]]></artwork></figure></t>
470    </list></t>
471        </section> -->
472        </section>
473        <section anchor="ecdsa-sigs" numbered="true" toc="default">
474          <name>ECDSA Signatures</name>
475          <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 
476       <xref target="X9.62" format="default"/>. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
477   (specified in <xref target="oids" format="default"/>) algorithm identifier appears, the respective SHAKE 
478   function (SHAKE128 or SHAKE256) is used as the hash. 
479   The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier 
480   SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or 
481   id-ecdsa-with-shake256.</t>
482          <t>For simplicity and compliance with the ECDSA standard specification, 
483       the output length of the hash function must be explicitly determined. The 
484       output length, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 256 or 512  
485   bits, respectively. </t>
486          <t>Conforming CA implementations that generate ECDSA with SHAKE signatures 
487   in certificates or CRLs SHOULD generate such signatures with a 
488   deterministically generated, non-random k in accordance with all 
489   the requirements specified in <xref target="RFC6979" format="default"/>. 
490   <!-- Sections 7.2 and 7.3 of 
491   <xref target="X9.62"/> or with all the requirements specified in Section 
492   4.1.3 of <xref target="SEC1"/>. -->
493   They MAY also generate such signatures 
494   in accordance with all other recommendations in <xref target="X9.62" format="default"/> or 
495   <xref target="SEC1" format="default"/> if they have a stated policy that requires 
496   conformance to those standards. Those standards have not specified  
497   SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and 
498   SHAKE256 with output length being 32 and 64 octets, respectively, can  
499   be used instead of 256 and 512-bit output hash algorithms such as SHA256 
500   and SHA512.</t>
501          <!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC6979"/>, HMAC is used to derive 
502   the deterministic k. Conforming implementations that generate deterministic 
503   ECDSA with SHAKE signatures in X.509 MUST use KMAC with SHAKE128 or KMAC with 
504   SHAKE256 as specfied in <xref target="SP800-185"/> when SHAKE128 or SHAKE256 is 
505   used as the message hashing algorithm, respectively. In this situation, KMAC with 
506   SHAKE128 and KMAC with SHAKE256 have 256-bit and 512-bit outputs respectively, 
507   and the optional customization bit string S is an empty string.</t> -->
508        </section>
509      </section>
510      <section numbered="true" toc="default">
511        <name>Public Keys</name>
512        <t>Certificates conforming to <xref target="RFC5280" format="default"/> can convey a 
513 public key for any public key algorithm. The certificate indicates 
514 the public key algorithm through an algorithm identifier. This algorithm 
515 identifier is an OID and optionally associated parameters.
516 The conventions and encoding for RSASSA-PSS and ECDSA <!-- and EdDSA --> 
517 public keys algorithm identifiers are as specified in 
518 Section 2.3.1 and 2.3.5 of <xref target="RFC3279" format="default"/>, 
519 Section 3.1 of <xref target="RFC4055" format="default"/> 
520 and Section 2.1 of <xref target="RFC5480" format="default"/>.
521 <!-- and <xref target="I-D.josefsson-pkix-eddsa"/>-->
522        </t>
523        <t>Traditionally, the rsaEncryption object identifier is used to
524 identify RSA public keys. The rsaEncryption object identifier 
525 continues to identify the subject public key when the RSA private 
526 key owner does not wish to limit the use of the public key 
527 exclusively to RSASSA-PSS with SHAKEs. When the RSA private 
528 key owner wishes to limit the use of the public key exclusively 
529 to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for 
530 RSASSA-PSS defined in <xref target="oids" format="default"/> SHOULD be used as the algorithm 
531 field in the SubjectPublicKeyInfo sequence <xref target="RFC5280" format="default"/>. 
532 Conforming client implementations that process RSASSA-PSS 
533 with SHAKE public keys when processing certificates and CRLs MUST 
534 recognize the corresponding OIDs. </t>
535        <t>Conforming CA implementations MUST specify the X.509 public key 
536 algorithm explicitly by using the OIDs specified in <xref target="oids" format="default"/> 
537 when encoding ECDSA with SHAKE public keys in certificates and CRLs. 
538 Conforming client implementations that process ECDSA with 
539 SHAKE public keys when processing certificates and CRLs MUST recognize 
540 the corresponding OIDs. </t>
541        <t>The identifier parameters, as explained in <xref target="oids" format="default"/>, 
542 MUST be absent.</t>
543      </section>
544    </section>
545    <section anchor="IANA" numbered="true" toc="default">
546      <name>IANA Considerations</name>
547      <t>One object identifier for the ASN.1 module in <xref target="asn" format="default"/> 
548   is requested for the SMI Security for PKIX Module Identifiers 
549   (1.3.6.1.5.5.7.0) registry: </t>
550      <table align="center">
551        <thead>
552          <tr>
553            <th align="center">Decimal</th>
554            <th align="center">Description</th>
555            <th align="center">References</th>
556          </tr>
557        </thead>
558        <tbody>
559          <tr>
560            <td align="center">TBD</td>
561            <td align="center">id-mod-pkix1-shakes-2019</td>
562            <td align="center">[EDNOTE: THIS RFC]</td>
563          </tr>
564        </tbody>
565      </table>
566      <t>IANA is requested to update the 
567   SMI Security for PKIX Algorithms <xref target="SMI-PKIX" format="default"/>
568   (1.3.6.1.5.5.7.6) registry with four additional entries: </t>
569      <table align="center">
570        <thead>
571          <tr>
572            <th align="center">Decimal</th>
573            <th align="center">Description</th>
574            <th align="center">References</th>
575          </tr>
576        </thead>
577        <tbody>
578          <tr>
579            <td align="center">TBD1</td>
580            <td align="center">id-RSASSA-PSS-SHAKE128</td>
581            <td align="center">[EDNOTE: THIS RFC]</td>
582          </tr>
583          <tr>
584            <td align="center">TBD2</td>
585            <td align="center">id-RSASSA-PSS-SHAKE256</td>
586            <td align="center">[EDNOTE: THIS RFC]</td>
587          </tr>
588          <tr>
589            <td align="center">TBD3</td>
590            <td align="center">id-ecdsa-with-shake128</td>
591            <td align="center">[EDNOTE: THIS RFC]</td>
592          </tr>
593          <tr>
594            <td align="center">TBD4</td>
595            <td align="center">id-ecdsa-with-shake256</td>
596            <td align="center">[EDNOTE: THIS RFC]</td>
597          </tr>
598        </tbody>
599      </table>
600      <t>IANA is also requested to update the 
601   Hash Function Textual Names Registry <xref target="Hash-Texts" format="default"/>
602      with two additional entries for SHAKE128
603      and SHAKE256: </t>
604      <table align="center">
605        <thead>
606          <tr>
607            <th align="center">Hash Function Name</th>
608            <th align="center">OID</th>
609            <th align="center">Reference</th>
610          </tr>
611        </thead>
612        <tbody>
613          <tr>
614            <td align="center">shake128</td>
615            <td align="center">2.16.840.1.101.3.4.2.11</td>
616            <td align="center">[EDNOTE: THIS RFC]</td>
617          </tr>
618          <tr>
619            <td align="center">shake256</td>
620            <td align="center">2.16.840.1.101.3.4.2.12</td>
621            <td align="center">[EDNOTE: THIS RFC]</td>
622          </tr>
623        </tbody>
624      </table>
625    </section>
626    <section anchor="Security" numbered="true" toc="default">
627      <name>Security Considerations</name>
628      <t>This document updates <xref target="RFC3279" format="default"/>. The security considerations
629      section of that document applies to this specification as well.</t>
630      <t>NIST has defined appropriate use of the hash functions in terms of the algorithm 
631      strengths and expected time frames for secure use in Special Publications (SPs) 
632      <xref target="SP800-78-4" format="default"/> and <xref target="SP800-107" format="default"/>. 
633      These documents can be used as guides to choose appropriate key sizes 
634      for various security scenarios. </t>
635      <!-- <t>The SHAKEs are deterministic functions. Like any other deterministic function, 
636   executing multiple times with the same input will produce the 
637   same output. Therefore, users should not expect unrelated outputs (with the 
638   same or different output lengths) from running a SHAKE function with the 
639   same input multiple times. The shorter of any two outputs produced from a 
640   SHAKE with the same input is a prefix of the longer one. It is a similar 
641   situation as truncating a 512-bit output of SHA-512 by taking its 256 
642   left-most bits. These 256 left-most bits are a prefix of the 512-bit output.</t> -->
643      <!-- <t>Implementations must protect the signer's private key. Compromise of
644      the signer's private key permits masquerade attacks.</t> -->
645      <!-- <t>Implementations must randomly generate one-time values, such as the k value when generating a ECDSA
646      signature. In addition, the generation of public/private key pairs
647      relies on random numbers. The use of inadequate pseudo-random
648      number generators (PRNGs) to generate such cryptographic values can
649      result in little or no security. The generation of quality random
650      numbers is difficult. <xref target="RFC4086"/> offers important guidance 
651   in this area, and <xref target="SP800-90A"/> series provide acceptable 
652      PRNGs.</t> -->
653      <!-- <t>Implementers should be aware that cryptographic algorithms may 
654   become weaker with time. As new cryptanalysis techniques are developed 
655   and computing power increases, the work factor or time required to break a 
656   particular cryptographic algorithm may decrease. Therefore, cryptographic
657      algorithm implementations should be modular allowing new algorithms
658      to be readily inserted. That is, implementers should be prepared to
659      regularly update the set of algorithms in their implementations.</t> -->
660      <t>SHAKE128 with output length of 256-bits offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are RECOMMENDED with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with group order of 256-bits (128-bit security). SHAKE256 with 512-bits output length offers 256-bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification are RECOMMENDED with 4096-bit RSA modulus or higher or curves with group order of at least 512 bits such as NIST Curve P-521 (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology.</t>
661    </section>
662    <!-- Possibly a 'Contributors' section ... -->
663    <section anchor="Acknowledgements" numbered="true" toc="default">
664      <name>Acknowledgements</name>
665      <t>We would like to thank Sean Turner, Jim Schaad and Eric 
666   Rescorla for their valuable contributions to this document.</t>
667      <t>The authors would like to thank Russ Housley for his guidance and 
668   very valuable contributions with the ASN.1 module.</t>
669    </section>
670  </middle>
671  <!--  *****BACK MATTER ***** -->
672  <back>
673    <!-- References split into informative and normative -->
674    <!-- There are 2 ways to insert reference entries from the citation libraries:
675     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
676     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
677        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
678
679     Both are cited textually in the same manner: by using xref elements.
680     If you use the PI option, xml2rfc will, by default, try to find included files in the same
681     directory as the including file. You can also define the XML_LIBRARY environment variable
682     with a value containing a set of directories to search.  These can be either in the local
683     filing system or remote ones accessed by http (http://domain/dir/... ).-->
684    <references>
685      <name>References</name>
686      <references>
687        <name>Normative References</name>
688        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
689        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
690          <front>
691            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
692            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
693            <seriesInfo name="RFC" value="2119"/>
694            <seriesInfo name="BCP" value="14"/>
695            <author initials="S." surname="Bradner" fullname="S. Bradner">
696              <organization/>
697            </author>
698            <date year="1997" month="March"/>
699            <abstract>
700              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
701            </abstract>
702          </front>
703        </reference>
704        <reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
705          <front>
706            <title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
707            <seriesInfo name="DOI" value="10.17487/RFC3279"/>
708            <seriesInfo name="RFC" value="3279"/>
709            <author initials="L." surname="Bassham" fullname="L. Bassham">
710              <organization/>
711            </author>
712            <author initials="W." surname="Polk" fullname="W. Polk">
713              <organization/>
714            </author>
715            <author initials="R." surname="Housley" fullname="R. Housley">
716              <organization/>
717            </author>
718            <date year="2002" month="April"/>
719            <abstract>
720              <t>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).  Digital signatures are used to sign certificates and certificate revocation list (CRLs).  Certificates include the public key of the named subject.  [STANDARDS-TRACK]</t>
721            </abstract>
722          </front>
723        </reference>
724        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
725          <front>
726            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
727            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
728            <seriesInfo name="RFC" value="8174"/>
729            <seriesInfo name="BCP" value="14"/>
730            <author initials="B." surname="Leiba" fullname="B. Leiba">
731              <organization/>
732            </author>
733            <date year="2017" month="May"/>
734            <abstract>
735              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
736            </abstract>
737          </front>
738        </reference>
739        <!-- &RFC3280; -->
740        <reference anchor="RFC4055" target="https://www.rfc-editor.org/info/rfc4055" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
741          <front>
742            <title>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
743            <seriesInfo name="DOI" value="10.17487/RFC4055"/>
744            <seriesInfo name="RFC" value="4055"/>
745            <author initials="J." surname="Schaad" fullname="J. Schaad">
746              <organization/>
747            </author>
748            <author initials="B." surname="Kaliski" fullname="B. Kaliski">
749              <organization/>
750            </author>
751            <author initials="R." surname="Housley" fullname="R. Housley">
752              <organization/>
753            </author>
754            <date year="2005" month="June"/>
755            <abstract>
756              <t>This document supplements RFC 3279.  It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified.  [STANDARDS-TRACK]</t>
757            </abstract>
758          </front>
759        </reference>
760        <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
761          <front>
762            <title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
763            <seriesInfo name="DOI" value="10.17487/RFC5280"/>
764            <seriesInfo name="RFC" value="5280"/>
765            <author initials="D." surname="Cooper" fullname="D. Cooper">
766              <organization/>
767            </author>
768            <author initials="S." surname="Santesson" fullname="S. Santesson">
769              <organization/>
770            </author>
771            <author initials="S." surname="Farrell" fullname="S. Farrell">
772              <organization/>
773            </author>
774            <author initials="S." surname="Boeyen" fullname="S. Boeyen">
775              <organization/>
776            </author>
777            <author initials="R." surname="Housley" fullname="R. Housley">
778              <organization/>
779            </author>
780            <author initials="W." surname="Polk" fullname="W. Polk">
781              <organization/>
782            </author>
783            <date year="2008" month="May"/>
784            <abstract>
785              <t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t>
786            </abstract>
787          </front>
788        </reference>
789        <reference anchor="RFC5480" target="https://www.rfc-editor.org/info/rfc5480" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
790          <front>
791            <title>Elliptic Curve Cryptography Subject Public Key Information</title>
792            <seriesInfo name="DOI" value="10.17487/RFC5480"/>
793            <seriesInfo name="RFC" value="5480"/>
794            <author initials="S." surname="Turner" fullname="S. Turner">
795              <organization/>
796            </author>
797            <author initials="D." surname="Brown" fullname="D. Brown">
798              <organization/>
799            </author>
800            <author initials="K." surname="Yiu" fullname="K. Yiu">
801              <organization/>
802            </author>
803            <author initials="R." surname="Housley" fullname="R. Housley">
804              <organization/>
805            </author>
806            <author initials="T." surname="Polk" fullname="T. Polk">
807              <organization/>
808            </author>
809            <date year="2009" month="March"/>
810            <abstract>
811              <t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279.  [STANDARDS-TRACK]</t>
812            </abstract>
813          </front>
814        </reference>
815        <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
816          <front>
817            <title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
818            <seriesInfo name="DOI" value="10.17487/RFC8017"/>
819            <seriesInfo name="RFC" value="8017"/>
820            <author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor">
821              <organization/>
822            </author>
823            <author initials="B." surname="Kaliski" fullname="B. Kaliski">
824              <organization/>
825            </author>
826            <author initials="J." surname="Jonsson" fullname="J. Jonsson">
827              <organization/>
828            </author>
829            <author initials="A." surname="Rusch" fullname="A. Rusch">
830              <organization/>
831            </author>
832            <date year="2016" month="November"/>
833            <abstract>
834              <t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
835              <t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t>
836              <t>This document also obsoletes RFC 3447.</t>
837            </abstract>
838          </front>
839        </reference>
840        <!-- 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 -->
841        <!-- <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-josefsson-pkix-eddsa-04.xml"?> -->
842        <reference anchor="SHA3" target="https://www.nist.gov/publications/sha-3-standard-permutation-based-hash-and-extendable-output-functions">
843          <front>
844            <title>SHA-3 Standard - Permutation-Based Hash and Extendable-Output Functions FIPS PUB 202</title>
845            <author>
846              <organization>National Institute of Standards and Technology (NIST)</organization>
847            </author>
848            <date month="August" year="2015"/>
849          </front>
850        </reference>
851      </references>
852      <references>
853        <name>Informative References</name>
854        <!-- Here we use entities that we defined at the beginning. -->
855        <!--&RFC2629; -->
856        <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
857          <front>
858            <title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
859            <seriesInfo name="DOI" value="10.17487/RFC5912"/>
860            <seriesInfo name="RFC" value="5912"/>
861            <author initials="P." surname="Hoffman" fullname="P. Hoffman">
862              <organization/>
863            </author>
864            <author initials="J." surname="Schaad" fullname="J. Schaad">
865              <organization/>
866            </author>
867            <date year="2010" month="June"/>
868            <abstract>
869              <t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t>
870            </abstract>
871          </front>
872        </reference>
873        <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml">
874          <front>
875            <title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
876            <seriesInfo name="DOI" value="10.17487/RFC6979"/>
877            <seriesInfo name="RFC" value="6979"/>
878            <author initials="T." surname="Pornin" fullname="T. Pornin">
879              <organization/>
880            </author>
881            <date year="2013" month="August"/>
882            <abstract>
883              <t>This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t>
884            </abstract>
885          </front>
886        </reference>
887        <!-- &RFC4086; -->
888        <!--<reference anchor="shake-nist-oids" target="https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm-Registration">
889        <front>
890          <title>Computer Security Objects Register</title>
891          <author>
892            <organization>National Institute of Standards and Technology</organization>
893          </author>
894          <date month="October" year="2017" />
895        </front>
896      </reference> -->
897        <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
898          <front>
899            <title>SEC 1: Elliptic Curve Cryptography</title>
900            <author>
901              <organization>Standards for Efficient Cryptography Group</organization>
902            </author>
903            <date month="May" year="2009"/>
904          </front>
905        </reference>
906        <reference anchor="X9.62">
907          <front>
908            <title>X9.62-2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)</title>
909            <author>
910              <organization>American National Standard for Financial Services (ANSI)</organization>
911            </author>
912            <date month="November" year="2005"/>
913          </front>
914        </reference>
915        <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">
916          <front>
917            <title>SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal Identity Verification</title>
918            <author>
919              <organization>National Institute of Standards and Technology (NIST)</organization>
920            </author>
921            <date month="May" year="2014"/>
922          </front>
923        </reference>
924        <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">
925          <front>
926            <title>SMI Security for PKIX Algorithms</title>
927            <author>
928              <organization>IANA</organization>
929            </author>
930            <date month="March" year="2019"/>
931          </front>
932        </reference>
933        <reference anchor="Hash-Texts" target="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml">
934          <front>
935            <title>Hash Function Textual Names</title>
936            <author>
937              <organization>IANA</organization>
938            </author>
939            <date month="July" year="2017"/>
940          </front>
941        </reference>
942        <reference anchor="SP800-107" target="https://csrc.nist.gov/csrc/media/publications/sp/800-107/rev-1/final/documents/draft_revised_sp800-107.pdf">
943          <front>
944            <title>SP800-107: Recommendation for Applications Using Approved Hash Algorithms</title>
945            <author>
946              <organization>National Institute of Standards and Technology (NIST)</organization>
947            </author>
948            <date month="May" year="2014"/>
949          </front>
950        </reference>
951        <!-- <reference anchor="SP800-90A" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
952        <front>
953          <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90A</title>
954          <author>
955            <organization>National Institute of Standards and Technology</organization>
956          </author>
957          <date month="June" year="2015" />
958        </front>
959      </reference> -->
960        <!-- <reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
961        <front>
962          <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. NIST SP 800-185</title>
963          <author>
964            <organization>National Institute of Standards and Technology</organization>
965          </author>
966          <date month="December" year="2016" />
967        </front>
968      </reference> -->
969      </references>
970    </references>
971    <section anchor="asn" numbered="true" toc="default">
972      <name>ASN.1 module</name>
973      <t>This appendix includes the ASN.1 module for SHAKEs in X.509. 
974    This module does not come from any existing RFC. </t>
975      <artwork name="" type="" align="left" alt=""><![CDATA[ 
976    PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6)
977      internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
978      id-mod-pkix1-shakes-2019(TBD) }
979
980    DEFINITIONS EXPLICIT TAGS ::=
981
982    BEGIN
983
984    -- EXPORTS ALL;
985
986    IMPORTS
987
988    -- FROM [RFC5912]
989
990    PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
991    FROM AlgorithmInformation-2009
992      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
993        mechanisms(5) pkix(7) id-mod(0)
994        id-mod-algorithmInformation-02(58) }
995
996    -- FROM [RFC5912]
997
998    RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,
999    CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value
1000    FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)
1001         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
1002         id-mod-pkix1-algorithms2008-02(56) }
1003   ;
1004
1005    --
1006    -- Message Digest Algorithms (mda-)
1007    --
1008    DigestAlgorithms DIGEST-ALGORITHM ::= {
1009      -- This expands DigestAlgorithms from [RFC5912]
1010      mda-shake128   |
1011      mda-shake256,
1012      ...
1013    }
1014
1015    --
1016    -- One-Way Hash Functions
1017    --
1018
1019    -- SHAKE128
1020    mda-shake128 DIGEST-ALGORITHM ::= {
1021      IDENTIFIER id-shake128  -- with output length 32 bytes.
1022    }
1023    id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
1024                                        us(840) organization(1) gov(101)
1025                                        csor(3) nistAlgorithm(4)
1026                                        hashAlgs(2) 11 }
1027
1028    -- SHAKE256
1029    mda-shake256 DIGEST-ALGORITHM ::= {
1030      IDENTIFIER id-shake256  -- with output length 64 bytes.
1031    }
1032    id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
1033                                        us(840) organization(1) gov(101)
1034                                        csor(3) nistAlgorithm(4)
1035                                        hashAlgs(2) 12 }
1036
1037    --
1038    -- Public Key (pk-) Algorithms
1039    --
1040    PublicKeys PUBLIC-KEY ::= {
1041      -- This expands PublicKeys from [RFC5912]
1042      pk-rsaSSA-PSS-SHAKE128 |
1043      pk-rsaSSA-PSS-SHAKE256,
1044      ...
1045    }
1046
1047    -- The hashAlgorithm is mda-shake128
1048    -- The maskGenAlgorithm is id-shake128
1049    -- Mask Gen Algorithm is SHAKE128 with output length
1050    -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 
1051    -- modulus in bits.
1052    -- The saltLength is 32. The trailerField is 1.
1053    pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= {
1054      IDENTIFIER id-RSASSA-PSS-SHAKE128
1055      KEY RSAPublicKey
1056      PARAMS ARE absent
1057      -- Private key format not in this module --
1058      CERT-KEY-USAGE { nonRepudiation, digitalSignature,
1059                       keyCertSign, cRLSign }
1060    }
1061
1062    -- The hashAlgorithm is mda-shake256
1063    -- The maskGenAlgorithm is id-shake256
1064    -- Mask Gen Algorithm is SHAKE256 with output length
1065    -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA 
1066    -- modulus in bits.
1067    -- The saltLength is 64. The trailerField is 1.
1068    pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= {
1069      IDENTIFIER id-RSASSA-PSS-SHAKE256
1070      KEY RSAPublicKey
1071      PARAMS ARE absent
1072      -- Private key format not in this module --
1073      CERT-KEY-USAGE { nonRepudiation, digitalSignature,
1074                       keyCertSign, cRLSign }
1075    }
1076
1077    --
1078    -- Signature Algorithms (sa-)
1079    --
1080    SignatureAlgs SIGNATURE-ALGORITHM ::= {
1081      -- This expands SignatureAlgorithms from [RFC5912]
1082      sa-rsassapssWithSHAKE128 |
1083      sa-rsassapssWithSHAKE256 |
1084      sa-ecdsaWithSHAKE128 |
1085      sa-ecdsaWithSHAKE256,
1086      ...
1087    }
1088
1089    --
1090    -- SMIME Capabilities (sa-)
1091    --
1092    SMimeCaps SMIME-CAPS ::= {
1093      -- The expands SMimeCaps from [RFC5912]
1094      sa-rsassapssWithSHAKE128.&smimeCaps |
1095      sa-rsassapssWithSHAKE256.&smimeCaps |
1096      sa-ecdsaWithSHAKE128.&smimeCaps |
1097      sa-ecdsaWithSHAKE256.&smimeCaps,
1098      ...
1099    }
1100
1101    -- RSASSA-PSS with SHAKE128
1102    sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {
1103      IDENTIFIER id-RSASSA-PSS-SHAKE128
1104      PARAMS ARE absent
1105          -- The hashAlgorithm is mda-shake128
1106          -- The maskGenAlgorithm is id-shake128
1107          -- Mask Gen Algorithm is SHAKE128 with output length
1108          -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 
1109          -- modulus in bits.
1110          -- The saltLength is 32. The trailerField is 1
1111      HASHES { mda-shake128 }
1112      PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 }
1113      SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
1114    }
1115    id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1) 
1116            identified-organization(3) dod(6) internet(1) 
1117            security(5) mechanisms(5) pkix(7) algorithms(6)
1118            TBD1 }
1119
1120    -- RSASSA-PSS with SHAKE256
1121    sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
1122      IDENTIFIER id-RSASSA-PSS-SHAKE256
1123      PARAMS ARE absent
1124          -- The hashAlgorithm is mda-shake256
1125          -- The maskGenAlgorithm is id-shake256
1126          -- Mask Gen Algorithm is SHAKE256 with output length
1127          -- (8*ceil((n-1)/8) - 520)-bits, where n is the 
1128          -- RSA modulus in bits.
1129          -- The saltLength is 64. The trailerField is 1.
1130     HASHES { mda-shake256 }
1131     PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 }
1132     SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
1133    }
1134    id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1) 
1135            identified-organization(3) dod(6) internet(1) 
1136            security(5) mechanisms(5) pkix(7) algorithms(6)
1137            TBD2 }
1138
1139    -- ECDSA with SHAKE128
1140    sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
1141      IDENTIFIER id-ecdsa-with-shake128
1142      VALUE ECDSA-Sig-Value
1143      PARAMS ARE absent
1144      HASHES { mda-shake128 }
1145      PUBLIC-KEYS { pk-ec }
1146      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
1147    }
1148    id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1) 
1149            identified-organization(3) dod(6) internet(1) 
1150            security(5) mechanisms(5) pkix(7) algorithms(6)
1151            TBD3 } 
1152
1153    -- ECDSA with SHAKE256
1154    sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
1155      IDENTIFIER id-ecdsa-with-shake256
1156      VALUE ECDSA-Sig-Value
1157      PARAMS ARE absent
1158      HASHES { mda-shake256 }
1159      PUBLIC-KEYS { pk-ec }
1160      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
1161    }
1162    id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1) 
1163            identified-organization(3) dod(6) internet(1) 
1164            security(5) mechanisms(5) pkix(7) algorithms(6)
1165            TBD4 }
1166
1167    END
1168 ]]></artwork>
1169    </section>
1170  </back>
1171</rfc>
1<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
2<front>
3<title>Key words for use in RFCs to Indicate Requirement Levels</title>
4<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
5<date year="1997" month="March"/>
6<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="2119"/>
10<seriesInfo name="DOI" value="10.17487/RFC2119"/>
11</reference>
1<reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
2<front>
3<title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="L." surname="Bassham" fullname="L. Bassham"><organization/></author>
5<author initials="W." surname="Polk" fullname="W. Polk"><organization/></author>
6<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
7<date year="2002" month="April"/>
8<abstract><t>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).  Digital signatures are used to sign certificates and certificate revocation list (CRLs).  Certificates include the public key of the named subject.  [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name="RFC" value="3279"/>
11<seriesInfo name="DOI" value="10.17487/RFC3279"/>
12</reference>
1<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
2<front>
3<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
4<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
5<date year="2017" month="May"/>
6<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="8174"/>
10<seriesInfo name="DOI" value="10.17487/RFC8174"/>
11</reference>
1<reference anchor="RFC4055" target="https://www.rfc-editor.org/info/rfc4055" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
2<front>
3<title>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author>
5<author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author>
6<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
7<date year="2005" month="June"/>
8<abstract><t>This document supplements RFC 3279.  It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified.  [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name="RFC" value="4055"/>
11<seriesInfo name="DOI" value="10.17487/RFC4055"/>
12</reference>
1<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
2<front>
3<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="D." surname="Cooper" fullname="D. Cooper"><organization/></author>
5<author initials="S." surname="Santesson" fullname="S. Santesson"><organization/></author>
6<author initials="S." surname="Farrell" fullname="S. Farrell"><organization/></author>
7<author initials="S." surname="Boeyen" fullname="S. Boeyen"><organization/></author>
8<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
9<author initials="W." surname="Polk" fullname="W. Polk"><organization/></author>
10<date year="2008" month="May"/>
11<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
12</front>
13<seriesInfo name="RFC" value="5280"/>
14<seriesInfo name="DOI" value="10.17487/RFC5280"/>
15</reference>
1<reference anchor="RFC5480" target="https://www.rfc-editor.org/info/rfc5480" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
2<front>
3<title>Elliptic Curve Cryptography Subject Public Key Information</title>
4<author initials="S." surname="Turner" fullname="S. Turner"><organization/></author>
5<author initials="D." surname="Brown" fullname="D. Brown"><organization/></author>
6<author initials="K." surname="Yiu" fullname="K. Yiu"><organization/></author>
7<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
8<author initials="T." surname="Polk" fullname="T. Polk"><organization/></author>
9<date year="2009" month="March"/>
10<abstract><t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279.  [STANDARDS-TRACK]</t></abstract>
11</front>
12<seriesInfo name="RFC" value="5480"/>
13<seriesInfo name="DOI" value="10.17487/RFC5480"/>
14</reference>
1<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
2<front>
3<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
4<author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor"><organization/></author>
5<author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author>
6<author initials="J." surname="Jonsson" fullname="J. Jonsson"><organization/></author>
7<author initials="A." surname="Rusch" fullname="A. Rusch"><organization/></author>
8<date year="2016" month="November"/>
9<abstract><t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t><t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t><t>This document also obsoletes RFC 3447.</t></abstract>
10</front>
11<seriesInfo name="RFC" value="8017"/>
12<seriesInfo name="DOI" value="10.17487/RFC8017"/>
13</reference>
1<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
2<front>
3<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
4<author initials="P." surname="Hoffman" fullname="P. Hoffman"><organization/></author>
5<author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author>
6<date year="2010" month="June"/>
7<abstract><t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t></abstract>
8</front>
9<seriesInfo name="RFC" value="5912"/>
10<seriesInfo name="DOI" value="10.17487/RFC5912"/>
11</reference>
1<reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml">
2<front>
3<title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
4<author initials="T." surname="Pornin" fullname="T. Pornin"><organization/></author>
5<date year="2013" month="August"/>
6<abstract><t>This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t></abstract>
7</front>
8<seriesInfo name="RFC" value="6979"/>
9<seriesInfo name="DOI" value="10.17487/RFC6979"/>
10</reference>
  • <?xml version="1.0" encoding="utf-8"?>
  • <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
  • <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
  • <?rfc strict="yes" ?>
  • <?rfc toc="yes"?>
  • <?rfc tocdepth="4"?>
  • <?rfc symrefs="yes"?>
  • <?rfc sortrefs="yes" ?>
  • <?rfc compact="yes" ?>
  • <?rfc subcompact="no" ?>
  • <rfc category="std" docName="draft-ietf-lamps-pkix-shake-15" ipr="trust200902" updates="3279" obsoletes="" submissionType="IETF" xml:lang="en" version="3" number="9999" consensus="true" tocInclude="true" symRefs="true" sortRefs="true">
    • <-- xml2rfc v2v3 conversion 2.23.1 -->
    • <-- 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>
      • <seriesInfo name="Internet-Draft" "RFC" value="draft-ietf-lamps-pkix-shake-15" "9999" />
      • <-- 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" month="August"/>
      • <-- 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 the "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List Profile" (RFC3279) and describes the conventions for using the SHAKE function family in Internet X.509 certificates and revocation lists 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 numbered="true" toc="default">
        • <name>
          • Change Log
          • </name>
        • <t>
          • [ EDNOTE: Remove this section before publication. ]
          • </t>
        • <ul spacing="normal">
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-15: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Minor editorial nits.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-14: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Fixing error with incorrect preimage resistance bits for SHA128 and SHA256.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-13: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Addressing one applicable comment from Dan M. about sec levels while in secdir review of draft-ietf-lamps-cms-shakes.</li><li>Addressing comment from Scott B.'s opsdir review about references in the abstract.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-12: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Nits identified by Roman, Eric V. Ben K., Barry L. in ballot position review.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-11: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Nits identified by Roman in AD Review.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-10: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Updated IANA considerations section to request for OID assignments. </li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-09: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Fixed minor text nits.</li><li>Added text name allocation for SHAKEs in IANA considerations.</li><li>Updates in Sec Considerations section.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-08: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Small nits from Russ while in WGLC.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-07: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Incorporated Eric's suggestion from WGLC.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-06: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Added informative references.</li><li>Updated ASN.1 so it compiles.</li><li>Updated IANA considerations.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-05: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Added RFC8174 reference and text.</li><li>Explicitly explained why RSASSA-PSS-params are omitted in section 5.1.1.</li><li>Simplified Public Keys section by removing redundant info from RFCs.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-04: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Removed paragraph suggesting KMAC to be used in generating k in Deterministic ECDSA. That should be RFC6979-bis. </li><li>Removed paragraph from Security Considerations that talks about randomness of k because we are using deterministic ECDSA.</li><li>Various ASN.1 fixes.</li><li>Text fixes.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-03: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Updates based on suggestions and clarifications by Jim. </li><li>Added ASN.1.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-02: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in PKIX.</li><li>Added new OIDs for RSASSA-PSS that hardcode hash, salt and MGF, according the WG consensus.</li><li>Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage.</li><li>Removed the no longer used SHAKE OIDs from section 3.1.</li><li>Consolidated subsection for message digest algorithms.</li><li>Text fixes.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-01: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Changed titles and section names.</li><li>Removed DSA after WG discussions.</li><li>Updated shake OID names and parameters, added MGF1 section.</li><li>Updated RSASSA-PSS section.</li><li>Added Public key algorithm OIDs.</li><li>Populated Introduction and IANA sections.</li></ul>
            • </li>
          • <li>
            • <t xmlns:xi="http://www.w3.org/2001/XInclude">draft-ietf-lamps-pkix-shake-00: </t><ul xmlns:xi="http://www.w3.org/2001/XInclude" spacing="normal"><li>Initial version</li></ul>
            • </li>
          • </ul>
        • </section>
      • <section numbered="true" toc="default">
        • <name>
          • Introduction
          • </name>
        • <t>
          • <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3279" format="default"/> defines cryptographic algorithm identifiers for the Internet X.509 Certificate and Certificate Revocation Lists (CRL) profile <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5280" format="default"/>. This document updates RFC3279 and defines identifiers for several cryptographic algorithms that use variable length output SHAKE functions introduced in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SHA3" format="default"/> which can be used with .
          • </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 xmlns:xi="http://www.w3.org/2001/XInclude" target="SHA3" format="default"/>). 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/> and ECDSA <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="X9.62" format="default"/> and as the hash in the mask generation function (MGF) in RSASSA-PSS. A SHAKE can be used as the message digest function (to hash the message to be signed) in RSASSA-PSS <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/> and ECDSA <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="X9.62" format="default"/> 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" numbered="true" toc="default">
        • <name>
          • Terminology
          • </name>
        • <t>
          • The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">REQUIRED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD NOT</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">NOT RECOMMENDED</bcp14>", "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14>", and "OPTIONAL" "<bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">OPTIONAL</bcp14>" in this document are to be interpreted as described in BCP 14 <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC2119" format="default"/> "RFC2119"/> <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8174" format="default"/> "RFC8174"/> when, and only when, they appear in all capitals, as shown here.
          • </t>
        • </section>
      • <-- Terminology  [rfced] Please review the type attribute of each sourcecode
        element in this XML file. In particular, what type should be used
        for the sourcecode elements in Sections 3 and 4.1? Should these be
        type="asn.1" or something else? Or should these be tagged as artwork rather
        than as sourcecode?

        The current list of types is in Section 2.48.4 of RFC 7991.
        -->
      • <section anchor="oids" numbered="true" toc="default">
        • <name>
          • Identifiers
          • </name>
        • <-- 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>
        • <artwork name="" type="" align="left" alt="">
          • <sourcecode type="">

            •                     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 } 
            • </sourcecode>
          • </artwork>
        • <t>
          • The new algorithm identifiers of ECDSA signatures using SHAKEs are below.
          • </t>
        • <ul empty="true" spacing="normal">
          • <li>
            • <sourcecode type="">
              • <artwork xmlns:xi="http://www.w3.org/2001/XInclude" name="" type="" align="left" alt=""><![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>*    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 } 
              • </sourcecode>
            • </li>
          • </ul>
        • <-- <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 <bcp14>MUST</bcp14>  have a hashAlgorithm value that identifies 
            the hash used with MGF1. To use SHAKE as this hash, this parameter           MUST <bcp14>MUST</bcp14>  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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be absent. That is, the identifier SHALL <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14> be a SEQUENCE of one component, the OID.
          • </t>
        • <t>
          • Sections <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="rsa-sigs" format="default"/> "counter"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="ecdsa-sigs" format="default"/> "counter"/> 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 numbered="true" toc="default">
        • <name>
          • Use in PKIX
          • </name>
        • <section anchor="sigs" numbered="true" toc="default">
          • <name>
            • Signatures
            • </name>
          • <t>
            • Signatures are used in a number of different ASN.1 structures. As shown in the ASN.1 representation from <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5280" format="default"/> 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>
          • <artwork name="" type="" align="left" alt="">
            • <sourcecode type="asn.1">

              •                        Certificate  ::=  SEQUENCE  { 
                      tbsCertificate       TBSCertificate, 
                      signatureAlgorithm   AlgorithmIdentifier, 
                      signatureValue       BIT STRING  } 
              • </sourcecode>
            • </artwork>
          • <t>
            • The identifiers defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/> 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5280" format="default"/>. The parameters of these signature algorithms are absent as explained in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/>.
            • </t>
          • <t>
            • Conforming CA implementations MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> specify the algorithms explicitly by using the OIDs specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> recognize the corresponding OIDs. Encoding rules for RSASSA-PSS and ECDSA signature values are specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4055" format="default"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5480" format="default"/>, respectively.
            • </t>
          • <t>
            • When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA curve order SHOULD <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14> be chosen in line with the SHAKE output length. Refer to <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Security" format="default"/> for more details.
            • </t>
          • <section anchor="rsa-sigs" numbered="true" toc="default">
            • <name>
              • RSASSA-PSS Signatures
              • </name>
            • <t>
              • The RSASSA-PSS algorithm is defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/>. When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/> is used, the encoding MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifier SHALL <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14> be a SEQUENCE of one component, id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4055" format="default"/> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be the same: both SHAKE128 or both SHAKE256. The output length of the hash algorithm which hashes the message SHALL <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/>. sectionFormat="of" section="B.2.1"/>. 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/>. As explained in Step 9                 of section 9.1.1 of <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/>, sectionFormat="of" section="9.1.1"/>, 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be 32 bytes for id-RSASSA-PSS-SHAKE128 or 64 bytes for id-RSASSA-PSS-SHAKE256. Finally, the trailerField MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be 1, which represents the trailer field with hexadecimal value 0xBC <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC8017" format="default"/>.
              • </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 anchor="ecdsa-sigs" numbered="true" toc="default">
            • <name>
              • ECDSA Signatures
              • </name>
            • <t>
              • The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="X9.62" format="default"/>. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 (specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/>) algorithm identifier appears, the respective SHAKE function (SHAKE128 or SHAKE256) is used as the hash. The encoding MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifier SHALL <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHALL</bcp14> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be 256 or 512 bits, respectively.
              • </t>
            • <t>
              • Conforming CA implementations that generate ECDSA with SHAKE signatures in certificates or CRLs SHOULD <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14> generate such signatures with a deterministically generated, non-random k in accordance with all the requirements specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC6979" format="default"/>.
                <-- 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MAY</bcp14> also generate such signatures in accordance with all other recommendations in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="X9.62" format="default"/> or <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SEC1" format="default"/> 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 <bcp14>MUST</bcp14>  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 numbered="true" toc="default">
          • <name>
            • Public Keys
            • </name>
          • <t>
            • Certificates conforming to <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5280" format="default"/> 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 Sections <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3279" sectionFormat="of" section="2.3.1"/> and 2.3.5 of <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3279" format="default"/>, Section 3.1 of sectionFormat="of" section="2.3.5"/>, <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC4055" format="default"/> sectionFormat="of" section="3.1"/>, and Section 2.1 of <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5480" sectionFormat="of" section="2.1"/>. format="default"/>.
              <-- 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/> SHOULD <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">SHOULD</bcp14> be used as the algorithm field in the SubjectPublicKeyInfo sequence <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC5280" format="default"/>. Conforming client implementations that process RSASSA-PSS with SHAKE public keys when processing certificates and CRLs MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> recognize the corresponding OIDs.
            • </t>
          • <t>
            • Conforming CA implementations MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> specify the X.509 public key algorithm explicitly by using the OIDs specified in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/> 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 <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> recognize the corresponding OIDs.
            • </t>
          • <t>
            • The identifier parameters, as explained in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="oids" format="default"/>, MUST <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">MUST</bcp14> be absent.
            • </t>
          • </section>
        • </section>
      • <section anchor="IANA" numbered="true" toc="default">
        • <name>
          • IANA Considerations
          • </name>
        • <-- [rfced]  We have updated instances of "[RFC5912]" in the ASN.1 module in
          Appendix A to read "RFC 5912" to avoid using square-bracketed citation in
          sourcecode that could be extracted from the document. May we add a
          sentence before the module to explain that the ASN.1 module imports from
          RFC 5912 and use the square-bracketed ciation there?

          Perhaps:
          This ASN.1 module imports from [RFC5912].
          -->
        • <t>
          • One object identifier for the ASN.1 module in <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="asn" format="default"/> is requested for the SMI Security for PKIX Module Identifiers (1.3.6.1.5.5.7.0) registry:
          • </t>
        • <table align="center" "left" >
          • <thead>
            • <tr>
              • <th align="center" "left" >
                • Decimal
                • </th>
              • <th align="center" "left" >
                • Description
                • </th>
              • <th align="center" "left" >
                • References
                • </th>
              • </tr>
            • </thead>
          • <tbody>
            • <tr>
              • <td align="center" "left" >
                • TBD
                • </td>
              • <td align="center" "left" >
                • id-mod-pkix1-shakes-2019
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • </tbody>
          • </table>
        • <t>
          • IANA is requested to update the SMI Security for PKIX Algorithms <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SMI-PKIX" format="default"/> (1.3.6.1.5.5.7.6) registry with four additional entries:
          • </t>
        • <table align="center" "left" >
          • <thead>
            • <tr>
              • <th align="center" "left" >
                • Decimal
                • </th>
              • <th align="center" "left" >
                • Description
                • </th>
              • <th align="center" "left" >
                • References
                • </th>
              • </tr>
            • </thead>
          • <tbody>
            • <tr>
              • <td align="center" "left" >
                • TBD1
                • </td>
              • <td align="center" "left" >
                • id-RSASSA-PSS-SHAKE128
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • <tr>
              • <td align="center" "left" >
                • TBD2
                • </td>
              • <td align="center" "left" >
                • id-RSASSA-PSS-SHAKE256
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • <tr>
              • <td align="center" "left" >
                • TBD3
                • </td>
              • <td align="center" "left" >
                • id-ecdsa-with-shake128
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • <tr>
              • <td align="center" "left" >
                • TBD4
                • </td>
              • <td align="center" "left" >
                • id-ecdsa-with-shake256
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • </tbody>
          • </table>
        • <t>
          • IANA is also requested to update the Hash Function Textual Names Registry <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="Hash-Texts" format="default"/> with two additional entries for SHAKE128 and SHAKE256:
          • </t>
        • <table align="center" "left" >
          • <thead>
            • <tr>
              • <th align="center" "left" >
                • Hash Function Name
                • </th>
              • <th align="center" "left" >
                • OID
                • </th>
              • <th align="center" "left" >
                • Reference
                • </th>
              • </tr>
            • </thead>
          • <tbody>
            • <tr>
              • <td align="center" "left" >
                • shake128
                • </td>
              • <td align="center" "left" >
                • 2.16.840.1.101.3.4.2.11
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • <tr>
              • <td align="center" "left" >
                • shake256
                • </td>
              • <td align="center" "left" >
                • 2.16.840.1.101.3.4.2.12
                • </td>
              • <td align="center" "left" >
                • [EDNOTE: THIS RFC] RFC 9999
                • </td>
              • </tr>
            • </tbody>
          • </table>
        • </section>
      • <section anchor="Security" numbered="true" toc="default">
        • <name>
          • Security Considerations
          • </name>
        • <t>
          • This document updates <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="RFC3279" format="default"/>. 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 xmlns:xi="http://www.w3.org/2001/XInclude" target="SP800-78-4" format="default"/> and <xref xmlns:xi="http://www.w3.org/2001/XInclude" target="SP800-107" format="default"/>. 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> -->
        • <t>
          • SHAKE128 with output length of 256-bits offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are RECOMMENDED <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">RECOMMENDED</bcp14> with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with group order of 256-bits (128-bit security). SHAKE256 with 512-bits output length offers 256-bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification are RECOMMENDED <bcp14 xmlns:xi="http://www.w3.org/2001/XInclude">RECOMMENDED</bcp14> with 4096-bit RSA modulus or higher or curves with group order of at least 512 bits such as NIST Curve P-521 (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology.
          • </t>
        • </section>
      • <-- Possibly a 'Contributors' section ... -->
      • <section anchor="Acknowledgements" numbered="true" toc="default">
        • <name>
          • Acknowledgements
          • </name>
        • <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>
        • <name>
          • References
          • </name>
        • <references>
          • <name>
            • Normative References
            • </name>
          • <--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
          • <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
            • <front>
              • <title>
                • Key words for use in RFCs to Indicate Requirement Levels
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC2119"/>
              • <seriesInfo name="RFC" value="2119"/>
              • <seriesInfo name="BCP" value="14"/>
              • <author initials="S." surname="Bradner" fullname="S. Bradner">
                • <organization/>
                • </author>
              • <date year="1997" month="March"/>
              • <abstract>
                • <t>
                  • In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="14"/>
            • <seriesInfo name="RFC" value="2119"/>
            • <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            • </reference>
          • <reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
            • <reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
              • <front>
                • <title>
                  • Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
                  • </title>
                • <seriesInfo name="DOI" value="10.17487/RFC3279"/>
                • <seriesInfo name="RFC" value="3279"/>
                • <author initials="L." surname="Bassham" fullname="L. Bassham">
                  • <organization/>
                  • </author>
                • <author initials="W." surname="Polk" fullname="W. Polk">
                  • <organization/>
                  • </author>
                • <author initials="R." surname="Housley" fullname="R. Housley">
                  • <organization/>
                  • </author>
                • <date year="2002" month="April"/>
                • <abstract>
                  • <t>
                    • This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI). Digital signatures are used to sign certificates and certificate revocation list (CRLs). Certificates include the public key of the named subject. [STANDARDS-TRACK]
                    • </t>
                  • </abstract>
                • </front>
              • </reference>
            • </reference>
          • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
            • <front>
              • <title>
                • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC8174"/>
              • <seriesInfo name="RFC" value="8174" "3279" />
              • <seriesInfo name="BCP" "DOI" value="14" "10.17487/RFC3279" />
              • <author initials="B." surname="Leiba" fullname="B. Leiba">
                • <organization/>
                • </author>
              • <date year="2017" month="May"/>
              • <abstract>
                • <t>
                  • RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                  • </t>
                • </abstract>
              • </front>
            • </reference>
          • <-- &RFC3280; -->
          • <reference anchor="RFC4055" target="https://www.rfc-editor.org/info/rfc4055" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
            • <front>
              • <title>
                • Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC4055"/>
              • <seriesInfo name="RFC" value="4055"/>
              • <author initials="J." surname="Schaad" fullname="J. Schaad">
                • <organization/>
                • </author>
              • <author initials="B." surname="Kaliski" fullname="B. Kaliski">
                • <organization/>
                • </author>
              • <author initials="R." surname="Housley" fullname="R. Housley">
                • <organization/>
                • </author>
              • <date year="2005" month="June"/>
              • <abstract>
                • <t>
                  • This document supplements RFC 3279. It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI). Encoding formats, algorithm identifiers, and parameter formats are specified. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="4055"/>
            • <seriesInfo name="DOI" value="10.17487/RFC4055"/>
            • </reference>
          • <reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
            • <front>
              • <title>
                • Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5280"/>
              • <seriesInfo name="RFC" value="5280"/>
              • <author initials="D." surname="Cooper" fullname="D. Cooper">
                • <organization/>
                • </author>
              • <author initials="S." surname="Santesson" fullname="S. Santesson">
                • <organization/>
                • </author>
              • <author initials="S." surname="Farrell" fullname="S. Farrell">
                • <organization/>
                • </author>
              • <author initials="S." surname="Boeyen" fullname="S. Boeyen">
                • <organization/>
                • </author>
              • <author initials="R." surname="Housley" fullname="R. Housley">
                • <organization/>
                • </author>
              • <author initials="W." surname="Polk" fullname="W. Polk">
                • <organization/>
                • </author>
              • <date year="2008" month="May"/>
              • <abstract>
                • <t>
                  • This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5280"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5280"/>
            • </reference>
          • <reference anchor="RFC5480" target="https://www.rfc-editor.org/info/rfc5480" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
            • <front>
              • <title>
                • Elliptic Curve Cryptography Subject Public Key Information
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5480"/>
              • <seriesInfo name="RFC" value="5480"/>
              • <author initials="S." surname="Turner" fullname="S. Turner">
                • <organization/>
                • </author>
              • <author initials="D." surname="Brown" fullname="D. Brown">
                • <organization/>
                • </author>
              • <author initials="K." surname="Yiu" fullname="K. Yiu">
                • <organization/>
                • </author>
              • <author initials="R." surname="Housley" fullname="R. Housley">
                • <organization/>
                • </author>
              • <author initials="T." surname="Polk" fullname="T. Polk">
                • <organization/>
                • </author>
              • <date year="2009" month="March"/>
              • <abstract>
                • <t>
                  • This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography. This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279. [STANDARDS-TRACK]
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5480"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5480"/>
            • </reference>
          • <reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
            • <front>
              • <title>
                • PKCS #1: RSA Cryptography Specifications Version 2.2
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC8017"/>
              • <seriesInfo name="RFC" value="8017"/>
              • <author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor">
                • <organization/>
                • </author>
              • <author initials="B." surname="Kaliski" fullname="B. Kaliski">
                • <organization/>
                • </author>
              • <author initials="J." surname="Jonsson" fullname="J. Jonsson">
                • <organization/>
                • </author>
              • <author initials="A." surname="Rusch" fullname="A. Rusch">
                • <organization/>
                • </author>
              • <date year="2016" month="November"/>
              • <abstract>
                • <t>
                  • This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.
                  • </t>
                • <t>
                  • This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.
                  • </t>
                • <t>
                  • This document also obsoletes RFC 3447.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="8017"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8017"/>
            • </reference>
          • <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
            • <front>
              • <title>
                • Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
                • </title>
              • <author initials="B." surname="Leiba" fullname="B. Leiba">
                • <organization/>
                • </author>
              • <date year="2017" month="May"/>
              • <abstract>
                • <t>
                  • RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="BCP" value="14"/>
            • <seriesInfo name="RFC" value="8174"/>
            • <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            • </reference>
          • <-- 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>
          • <name>
            • Informative References
            • </name>
          • <-- Here we use entities that we defined at the beginning. -->
          • <--&RFC2629; -->
          • <reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
            • <front>
              • <title>
                • New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC5912"/>
              • <seriesInfo name="RFC" value="5912"/>
              • <author initials="P." surname="Hoffman" fullname="P. Hoffman">
                • <organization/>
                • </author>
              • <author initials="J." surname="Schaad" fullname="J. Schaad">
                • <organization/>
                • </author>
              • <date year="2010" month="June"/>
              • <abstract>
                • <t>
                  • The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1. The current ASN.1 modules conform to the 1988 version of ASN.1. This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax. This document is not an Internet Standards Track specification; it is published for informational purposes.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="5912"/>
            • <seriesInfo name="DOI" value="10.17487/RFC5912"/>
            • </reference>
          • <reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml">
            • <front>
              • <title>
                • Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)
                • </title>
              • <seriesInfo name="DOI" value="10.17487/RFC6979"/>
              • <seriesInfo name="RFC" value="6979"/>
              • <author initials="T." surname="Pornin" fullname="T. Pornin">
                • <organization/>
                • </author>
              • <date year="2013" month="August"/>
              • <abstract>
                • <t>
                  • This document defines a deterministic digital signature generation procedure. Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein. Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.
                  • </t>
                • </abstract>
              • </front>
            • <seriesInfo name="RFC" value="6979"/>
            • <seriesInfo name="DOI" value="10.17487/RFC6979"/>
            • </reference>
          • <-- &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>
        • </references>
      • <section anchor="asn" numbered="true" toc="default">
        • <name>
          • ASN.1 module
          • </name>
        • <t>
          • This appendix includes the ASN.1 module for SHAKEs in X.509. This module does not come from any existing RFC.
          • </t>
        • <artwork name="" type="" align="left" alt="">
          • <sourcecode type="asn.1">
            •  
                                    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

              =      BEGIN       -- EXPORTS ALL;  

                  IMPORTS  

                  -- FROM [RFC5912]

               RFC 5912       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]

               RFC 5912       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]
               RFC 5912        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]
               RFC 5912        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]
               RFC 5912        sa-rsassapssWithSHAKE128 | 
                    sa-rsassapssWithSHAKE256 | 
                    sa-ecdsaWithSHAKE128 | 
                    sa-ecdsaWithSHAKE256, 
                    ... 
                  }  

                  -- 
                  -- SMIME Capabilities (sa-) 
                  -- 
                  SMimeCaps SMIME-CAPS ::= { 
                    -- The expands SMimeCaps from [RFC5912]
               RFC 5912        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 
            • </sourcecode>
          • </artwork>
        • </section>
      • </back>
    • </rfc>
1<?xml version='1.0' encoding='utf-8'?>
2
3<rfc number="9999" consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude" category="std"
4     ipr="trust200902" updates="3279"
5     obsoletes="" submissionType="IETF" xml:lang="en" tocInclude="true"
6     symRefs="true" sortRefs="true" version="3">
7
8  <!-- ***** FRONT MATTER ***** -->
9  <front>
10
11    <title abbrev="SHAKE identifiers in X.509">Internet X.509 Public Key Infrastructure: Additional Algorithm Identifiers for RSASSA-PSS and ECDSA using SHAKEs</title>
12
13    <seriesInfo name="RFC" value="9999"/>
14
15    <author fullname="Panos Kampanakis" initials="P.K." surname="Kampanakis">
16      <organization>Cisco Systems</organization>
17      <address>
18        <email>pkampana@cisco.com</email>
19      </address>
20    </author>
21    <author fullname="Quynh Dang" initials="Q.D." surname="Dang">
22      <organization>NIST</organization>
23      <address>
24        <postal>
25          <street>100 Bureau Drive, Stop 8930</street>
26          <city>Gaithersburg</city>
27          <region>MD</region>
28          <code>20899-8930</code>
29          <country>USA</country>
30        </postal>
31
32        <email>quynh.dang@nist.gov</email>
33
34      </address>
35    </author>
36
37    <date month="August" year="2019"/>
38
39    <area>General</area>
40    <workgroup>LAMPS WG</workgroup>
41
42    <abstract>
43      <t>Digital signatures are used to sign messages, X.509 
44   certificates and CRLs. This document updates the 
45   "Algorithms and Identifiers for the Internet 
46   X.509 Public Key Infrastructure Certificate and 
47   Certificate Revocation List Profile" (RFC3279)
48   and describes the conventions for using the SHAKE function 
49   family in Internet X.509 certificates and revocation lists 
50   as one-way hash functions with the RSA Probabilistic signature 
51   and ECDSA signature algorithms. The conventions for the 
52   associated subject public keys are also described.</t>
53    </abstract>
54  </front>
55  <middle>
56
57
58    <section numbered="true" toc="default">
59      <name>Introduction</name>
60      <t><xref target="RFC3279" format="default"/> defines cryptographic algorithm 
61   identifiers for the Internet X.509 Certificate and Certificate Revocation 
62   Lists (CRL) profile <xref target="RFC5280" format="default"/>. This document updates RFC3279 
63   and defines identifiers for several cryptographic algorithms that use 
64   variable length output SHAKE functions introduced in <xref target="SHA3" format="default"/> 
65   which can be used with . </t>
66      <t>In the SHA-3 family, two extendable-output functions (SHAKEs),  
67   SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256, 
68   SHA3-384, and SHA3-512, are also defined but are out of scope for this document. 
69   A SHAKE is a variable length hash function defined as SHAKE(M, d) where the 
70   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) 
71   bits, respectively (Appendix A.1 <xref target="SHA3" format="default"/>). 
72   And the corresponding collision and second-preimage-resistance strengths for SHAKE256 
73   are min(d/2,256) and min(d,256) bits, respectively.</t>
74      <t>A SHAKE can be used as the message digest function (to hash the message to be signed) 
75   in RSASSA-PSS <xref target="RFC8017" format="default"/> and ECDSA <xref target="X9.62" format="default"/> 
76      and as the hash in the mask generation function (MGF) in RSASSA-PSS. 
77</t>
78    </section>
79
80    <section anchor="terminology" numbered="true" toc="default">
81      <name>Terminology</name>
82
83        <t>
84    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
85    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
86    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
87    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
88    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
89    interpreted as described in BCP 14 <xref target="RFC2119"/> <xref
90    target="RFC8174"/> when, and only when, they appear in all capitals, as
91    shown here.
92        </t>
93
94
95    </section>
96
97<!-- [rfced] Please review the type attribute of each sourcecode
98element in this XML file. In particular, what type should be used
99for the sourcecode elements in Sections 3 and 4.1? Should these be
100type="asn.1" or something else? Or should these be tagged as artwork rather
101than as sourcecode?
102
103The current list of types is in Section 2.48.4 of RFC 7991.
104-->
105
106    <section anchor="oids" numbered="true" toc="default">
107      <name>Identifiers</name>
108
109      <t>This section defines four new object identifiers (OIDs), for RSASSA-PSS and ECDSA with each 
110   of SHAKE128 and SHAKE256. The same algorithm identifiers can be  
111   used for identifying a public key in RSASSA-PSS.</t>
112      <t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below.</t>
113
114      <sourcecode type=""><![CDATA[
115  id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1) 
116            identified-organization(3) dod(6) internet(1) 
117            security(5) mechanisms(5) pkix(7) algorithms(6)
118            TBD1 }
119
120  id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1) 
121            identified-organization(3) dod(6) internet(1) 
122            security(5) mechanisms(5) pkix(7) algorithms(6)
123            TBD2 }
124]]></sourcecode>
125
126      <t>The new algorithm identifiers of ECDSA signatures using SHAKEs are below.</t>
127
128          <sourcecode type=""><![CDATA[
129  id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1) 
130            identified-organization(3) dod(6) internet(1) 
131            security(5) mechanisms(5) pkix(7) algorithms(6)
132            TBD3 }            
133
134  id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1) 
135            identified-organization(3) dod(6) internet(1) 
136            security(5) mechanisms(5) pkix(7) algorithms(6)
137            TBD4 }
138]]></sourcecode>
139
140      <!-- <xref target="RFC8017"/>, but we include it here as well for convenience:</t>
141   <t><figure><artwork><![CDATA[
142   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }
143]]></artwork></figure>-->
144      <!-- <t>The parameters field associated with id-mgf1 <bcp14>MUST</bcp14> have a hashAlgorithm value that identifies 
145   the hash used with MGF1. To use SHAKE as this hash, this parameter <bcp14>MUST</bcp14> be 
146   id-shake128-len or id-shake256-len as specified in <xref target="xofs" /> above. </t>-->
147      <t>The parameters for the four identifiers above <bcp14>MUST</bcp14> be absent. That is, 
148   the identifier <bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID.</t>
149      <t>Sections <xref target="rsa-sigs" format="counter"/> and <xref target="ecdsa-sigs" format="counter"/> specify the required output length 
150   for each use of SHAKE128 or SHAKE256 in RSASSA-PSS and ECDSA. In summary, when hashing messages
151      to be signed, output lengths of SHAKE128 and SHAKE256 are 256 and 512 bits respectively. 
152   When the SHAKEs are used as mask generation functions RSASSA-PSS, their output length is 
153   (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>
154    </section>
155    <section numbered="true" toc="default">
156      <name>Use in PKIX</name>
157      <section anchor="sigs" numbered="true" toc="default">
158        <name>Signatures</name>
159        <t>Signatures are used in a number of different ASN.1 structures.
160        As shown in the ASN.1 representation from <xref target="RFC5280" format="default"/> 
161 below, in an X.509 certificate, a signature is encoded with an 
162 algorithm identifier in the signatureAlgorithm attribute and 
163 a signatureValue attribute that contains the actual signature.  
164        </t>
165        <sourcecode type="asn.1"><![CDATA[
166   Certificate  ::=  SEQUENCE  {
167      tbsCertificate       TBSCertificate,
168      signatureAlgorithm   AlgorithmIdentifier,
169      signatureValue       BIT STRING  }
170]]></sourcecode>
171        <t>The identifiers defined in <xref target="oids" format="default"/> can be used 
172 as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence 
173 Certificate and the signature field in the sequence TBSCertificate in X.509  
174 <xref target="RFC5280" format="default"/>. 
175 The parameters of these signature algorithms are absent as explained 
176 in <xref target="oids" format="default"/>.</t>
177        <t>Conforming CA implementations <bcp14>MUST</bcp14> specify the algorithms  
178 explicitly by using the OIDs specified in <xref target="oids" format="default"/> when 
179 encoding RSASSA-PSS or ECDSA with SHAKE signatures 
180 in certificates and CRLs.
181 Conforming client implementations that process certificates and CRLs 
182 using RSASSA-PSS or ECDSA with SHAKE <bcp14>MUST</bcp14> recognize the corresponding OIDs.
183 Encoding rules for RSASSA-PSS and ECDSA 
184 signature values are specified in <xref target="RFC4055" format="default"/> and 
185 <xref target="RFC5480" format="default"/>, respectively.</t>
186        <t>When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA 
187 curve order <bcp14>SHOULD</bcp14> be chosen in line with the SHAKE output length. 
188 Refer to <xref target="Security" format="default"/> for more details.</t>
189        <section anchor="rsa-sigs" numbered="true" toc="default">
190          <name>RSASSA-PSS Signatures</name>
191          <t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017" format="default"/>. 
192   When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in <xref target="oids" format="default"/> 
193   is used, the encoding <bcp14>MUST</bcp14> omit the parameters field. That is, 
194   the AlgorithmIdentifier <bcp14>SHALL</bcp14> be a SEQUENCE of one component,  
195   id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. <xref target="RFC4055" format="default"/>
196   defines RSASSA-PSS-params that are used to define the algorithms and inputs 
197   to the algorithm. This specification does not use parameters because the 
198   hash, mask generation algorithm, trailer and salt are embedded in 
199   the OID definition.</t>
200          <t>The hash algorithm to hash a message being signed and the hash algorithm used as the
201   mask generation function <!-- "MGF(H, emLen - hLen - 1)" <xref target="RFC8017"/> -->
202   in RSASSA-PSS <bcp14>MUST</bcp14> be the same: both SHAKE128 or both SHAKE256. The 
203   output length of the hash algorithm which hashes the message <bcp14>SHALL</bcp14> be 32 
204   (for SHAKE128) or 64 bytes (for SHAKE256). </t>
205          <t>The mask generation function takes an octet string of variable length and
206   a desired output length as input, and outputs an octet 
207   string of the desired length. In RSASSA-PSS with SHAKEs, the SHAKEs <bcp14>MUST</bcp14> be 
208   used natively as the MGF function, instead of the MGF1 algorithm that uses 
209   the hash function in multiple iterations as specified in
210   <xref target="RFC8017" sectionFormat="of" section="B.2.1"/>. In other words, the MGF is defined as 
211   <!-- <t><figure><artwork><![CDATA[
212    SHAKE128(mgfSeed, maskLen) 
213]]></artwork></figure>
214          and 
215          <figure><artwork><![CDATA[
216    SHAKE256(mgfSeed, maskLen)
217]]></artwork></figure></t> --> 
218          the SHAKE128 or SHAKE256 output of the mgfSeed for id-RSASSA-PSS-SHAKE128 and 
219   id-RSASSA-PSS-SHAKE256, respectively. The mgfSeed is the seed 
220   from which mask is generated, an octet string <xref target="RFC8017" format="default"/>.   
221   As explained in Step 9 of <xref target="RFC8017" sectionFormat="of" section="9.1.1"/>, the output 
222   length of the MGF is emLen - hLen - 1 bytes. emLen is the maximum message 
223   length ceil((n-1)/8), where n is the RSA modulus in bits. hLen is 32 and 
224   64-bytes for id-RSASSA-PSS-SHAKE128 and id-RSASSA-PSS-SHAKE256, respectively. 
225   Thus when SHAKE is used as the MGF, the SHAKE output length maskLen is 
226   (8*emLen - 264) or (8*emLen - 520) bits, respectively. For example, when RSA modulus n is 2048, 
227   the output length of SHAKE128 or SHAKE256 as the MGF will be 1784 or 1528-bits 
228   when id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 is used, respectively. </t>
229          <t>The RSASSA-PSS saltLength <bcp14>MUST</bcp14> be 32 bytes for id-RSASSA-PSS-SHAKE128 
230   or 64 bytes for id-RSASSA-PSS-SHAKE256. 
231   Finally, the trailerField <bcp14>MUST</bcp14> be 1, which represents 
232   the trailer field with hexadecimal value 0xBC <xref target="RFC8017" format="default"/>.</t>
233          <!-- <t><figure><artwork><![CDATA[
234   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 k }
235
236   RSASSA-PSS-params  ::=  SEQUENCE  {
237         hashAlgorithm      HashAlgorithm, 
238         maskGenAlgorithm   MaskGenAlgorithm, 
239         saltLength         INTEGER, 
240         trailerField       INTEGER }
241]]></artwork></figure></t> -->
242          <!-- <section title="EdDSA with SHAKE">
243          <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>
244   <t>
245      <list>
246    <t><figure><artwork><![CDATA[
247id-eddsa-with-shake128 OBJECT IDENTIFIER ::= { }
248]]></artwork></figure></t>
249    <t><figure><artwork><![CDATA[
250id-eddsa-with-shake256 OBJECT IDENTIFIER ::= {  }
251]]></artwork></figure></t>
252    </list></t>
253        </section> -->
254        </section>
255        <section anchor="ecdsa-sigs" numbered="true" toc="default">
256          <name>ECDSA Signatures</name>
257          <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 
258       <xref target="X9.62" format="default"/>. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256
259   (specified in <xref target="oids" format="default"/>) algorithm identifier appears, the respective SHAKE 
260   function (SHAKE128 or SHAKE256) is used as the hash. 
261   The encoding <bcp14>MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifier 
262   <bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or 
263   id-ecdsa-with-shake256.</t>
264          <t>For simplicity and compliance with the ECDSA standard specification, 
265       the output length of the hash function must be explicitly determined. The 
266       output length, d, for SHAKE128 or SHAKE256 used in ECDSA <bcp14>MUST</bcp14> be 256 or 512  
267   bits, respectively. </t>
268          <t>Conforming CA implementations that generate ECDSA with SHAKE signatures 
269   in certificates or CRLs <bcp14>SHOULD</bcp14> generate such signatures with a 
270   deterministically generated, non-random k in accordance with all 
271   the requirements specified in <xref target="RFC6979" format="default"/>. 
272
273   <!-- Sections 7.2 and 7.3 of 
274   <xref target="X9.62"/> or with all the requirements specified in Section 
275   4.1.3 of <xref target="SEC1"/>. -->
276
277   They <bcp14>MAY</bcp14> also generate such signatures 
278   in accordance with all other recommendations in <xref target="X9.62" format="default"/> or 
279   <xref target="SEC1" format="default"/> if they have a stated policy that requires 
280   conformance to those standards. Those standards have not specified  
281   SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and 
282   SHAKE256 with output length being 32 and 64 octets, respectively, can  
283   be used instead of 256 and 512-bit output hash algorithms such as SHA256 
284   and SHA512.</t>
285          <!-- <t>In Section 3.2 "Generation of k" of <xref target="RFC6979"/>, HMAC is used to derive 
286   the deterministic k. Conforming implementations that generate deterministic 
287   ECDSA with SHAKE signatures in X.509 <bcp14>MUST</bcp14> use KMAC with SHAKE128 or KMAC with 
288   SHAKE256 as specfied in <xref target="SP800-185"/> when SHAKE128 or SHAKE256 is 
289   used as the message hashing algorithm, respectively. In this situation, KMAC with 
290   SHAKE128 and KMAC with SHAKE256 have 256-bit and 512-bit outputs respectively, 
291   and the optional customization bit string S is an empty string.</t> -->
292        </section>
293      </section>
294      <section numbered="true" toc="default">
295        <name>Public Keys</name>
296        <t>Certificates conforming to <xref target="RFC5280" format="default"/> can convey a 
297 public key for any public key algorithm. The certificate indicates 
298 the public key algorithm through an algorithm identifier. This algorithm 
299 identifier is an OID and optionally associated parameters.
300 The conventions and encoding for RSASSA-PSS and ECDSA <!-- and EdDSA -->
301 public keys algorithm identifiers are as specified in 
302 Sections <xref target="RFC3279"
303 sectionFormat="of" section="2.3.1"/> and <xref
304 target="RFC3279" sectionFormat="of" section="2.3.5"/>, 
305 <xref target="RFC4055" sectionFormat="of" section="3.1"/>,
306 and <xref target="RFC5480" sectionFormat="of" section="2.1"/>.
307
308        </t>
309        <t>Traditionally, the rsaEncryption object identifier is used to
310 identify RSA public keys. The rsaEncryption object identifier 
311 continues to identify the subject public key when the RSA private 
312 key owner does not wish to limit the use of the public key 
313 exclusively to RSASSA-PSS with SHAKEs. When the RSA private 
314 key owner wishes to limit the use of the public key exclusively 
315 to RSASSA-PSS with SHAKEs, the AlgorithmIdentifiers for 
316 RSASSA-PSS defined in <xref target="oids" format="default"/> <bcp14>SHOULD</bcp14> be used as the algorithm 
317 field in the SubjectPublicKeyInfo sequence <xref target="RFC5280" format="default"/>. 
318 Conforming client implementations that process RSASSA-PSS 
319 with SHAKE public keys when processing certificates and CRLs <bcp14>MUST</bcp14> 
320 recognize the corresponding OIDs. </t>
321        <t>Conforming CA implementations <bcp14>MUST</bcp14> specify the X.509 public key 
322 algorithm explicitly by using the OIDs specified in <xref target="oids" format="default"/> 
323 when encoding ECDSA with SHAKE public keys in certificates and CRLs. 
324 Conforming client implementations that process ECDSA with 
325 SHAKE public keys when processing certificates and CRLs <bcp14>MUST</bcp14> recognize 
326 the corresponding OIDs. </t>
327        <t>The identifier parameters, as explained in <xref target="oids" format="default"/>, 
328 <bcp14>MUST</bcp14> be absent.</t>
329      </section>
330    </section>
331    <section anchor="IANA" numbered="true" toc="default">
332      <name>IANA Considerations</name>
333
334<!-- [rfced]  We have updated instances of "[RFC5912]" in the ASN.1 module in
335Appendix A to read "RFC 5912" to avoid using square-bracketed citation in
336sourcecode that could be extracted from the document. May we add a
337sentence before the module to explain that the ASN.1 module imports from
338RFC 5912 and use the square-bracketed ciation there?
339
340Perhaps:
341This ASN.1 module imports from [RFC5912].
342-->
343      <t>One object identifier for the ASN.1 module in <xref target="asn" format="default"/> 
344   is requested for the SMI Security for PKIX Module Identifiers 
345   (1.3.6.1.5.5.7.0) registry: </t>
346      <table align="left">
347        <thead>
348          <tr>
349            <th align="left">Decimal</th>
350            <th align="left">Description</th>
351            <th align="left">References</th>
352          </tr>
353        </thead>
354        <tbody>
355          <tr>
356            <td align="left">TBD</td>
357            <td align="left">id-mod-pkix1-shakes-2019</td>
358            <td align="left">RFC 9999</td>
359          </tr>
360        </tbody>
361      </table>
362      <t>IANA is requested to update the 
363   SMI Security for PKIX Algorithms <xref target="SMI-PKIX" format="default"/>
364   (1.3.6.1.5.5.7.6) registry with four additional entries: </t>
365      <table align="left">
366        <thead>
367          <tr>
368            <th align="left">Decimal</th>
369            <th align="left">Description</th>
370            <th align="left">References</th>
371          </tr>
372        </thead>
373        <tbody>
374          <tr>
375            <td align="left">TBD1</td>
376            <td align="left">id-RSASSA-PSS-SHAKE128</td>
377            <td align="left">RFC 9999</td>
378          </tr>
379          <tr>
380            <td align="left">TBD2</td>
381            <td align="left">id-RSASSA-PSS-SHAKE256</td>
382            <td align="left">RFC 9999</td>
383          </tr>
384          <tr>
385            <td align="left">TBD3</td>
386            <td align="left">id-ecdsa-with-shake128</td>
387            <td align="left">RFC 9999</td>
388          </tr>
389          <tr>
390            <td align="left">TBD4</td>
391            <td align="left">id-ecdsa-with-shake256</td>
392            <td align="left">RFC 9999</td>
393          </tr>
394        </tbody>
395      </table>
396      <t>IANA is also requested to update the 
397   Hash Function Textual Names Registry <xref target="Hash-Texts" format="default"/>
398      with two additional entries for SHAKE128
399      and SHAKE256: </t>
400      <table align="left">
401        <thead>
402          <tr>
403            <th align="left">Hash Function Name</th>
404            <th align="left">OID</th>
405            <th align="left">Reference</th>
406          </tr>
407        </thead>
408        <tbody>
409          <tr>
410            <td align="left">shake128</td>
411            <td align="left">2.16.840.1.101.3.4.2.11</td>
412            <td align="left">RFC 9999</td>
413          </tr>
414          <tr>
415            <td align="left">shake256</td>
416            <td align="left">2.16.840.1.101.3.4.2.12</td>
417            <td align="left">RFC 9999</td>
418          </tr>
419        </tbody>
420      </table>
421    </section>
422    <section anchor="Security" numbered="true" toc="default">
423      <name>Security Considerations</name>
424      <t>This document updates <xref target="RFC3279" format="default"/>. The security considerations
425      section of that document applies to this specification as well.</t>
426      <t>NIST has defined appropriate use of the hash functions in terms of the algorithm 
427      strengths and expected time frames for secure use in Special Publications (SPs) 
428      <xref target="SP800-78-4" format="default"/> and <xref target="SP800-107" format="default"/>. 
429      These documents can be used as guides to choose appropriate key sizes 
430      for various security scenarios. </t>
431      <!-- <t>The SHAKEs are deterministic functions. Like any other deterministic function, 
432   executing multiple times with the same input will produce the 
433   same output. Therefore, users should not expect unrelated outputs (with the 
434   same or different output lengths) from running a SHAKE function with the 
435   same input multiple times. The shorter of any two outputs produced from a 
436   SHAKE with the same input is a prefix of the longer one. It is a similar 
437   situation as truncating a 512-bit output of SHA-512 by taking its 256 
438   left-most bits. These 256 left-most bits are a prefix of the 512-bit output.</t> -->
439      <!-- <t>Implementations must protect the signer's private key. Compromise of
440      the signer's private key permits masquerade attacks.</t> -->
441      <!-- <t>Implementations must randomly generate one-time values, such as the k value when generating a ECDSA
442      signature. In addition, the generation of public/private key pairs
443      relies on random numbers. The use of inadequate pseudo-random
444      number generators (PRNGs) to generate such cryptographic values can
445      result in little or no security. The generation of quality random
446      numbers is difficult. <xref target="RFC4086"/> offers important guidance 
447   in this area, and <xref target="SP800-90A"/> series provide acceptable 
448      PRNGs.</t> -->
449      <!-- <t>Implementers should be aware that cryptographic algorithms may 
450   become weaker with time. As new cryptanalysis techniques are developed 
451   and computing power increases, the work factor or time required to break a 
452   particular cryptographic algorithm may decrease. Therefore, cryptographic
453      algorithm implementations should be modular allowing new algorithms
454      to be readily inserted. That is, implementers should be prepared to
455      regularly update the set of algorithms in their implementations.</t> -->
456      <t>SHAKE128 with output length of 256-bits offers 128-bits of collision and preimage resistance. Thus, SHAKE128 OIDs in this specification are <bcp14>RECOMMENDED</bcp14> with 2048 (112-bit security) or 3072-bit (128-bit security) RSA modulus or curves with group order of 256-bits (128-bit security). SHAKE256 with 512-bits output length offers 256-bits of collision and preimage resistance. Thus, the SHAKE256 OIDs in this specification are <bcp14>RECOMMENDED</bcp14> with 4096-bit RSA modulus or higher or curves with group order of at least 512 bits such as NIST Curve P-521 (256-bit security). Note that we recommended 4096-bit RSA because we would need 15360-bit modulus for 256-bits of security which is impractical for today's technology.</t>
457    </section>
458    <!-- Possibly a 'Contributors' section ... -->
459    <section anchor="Acknowledgements" numbered="true" toc="default">
460      <name>Acknowledgements</name>
461      <t>We would like to thank Sean Turner, Jim Schaad and Eric 
462   Rescorla for their valuable contributions to this document.</t>
463      <t>The authors would like to thank Russ Housley for his guidance and 
464   very valuable contributions with the ASN.1 module.</t>
465    </section>
466  </middle>
467  <!--  *****BACK MATTER ***** -->
468  <back>
469    <!-- References split into informative and normative -->
470    <!-- There are 2 ways to insert reference entries from the citation libraries:
471     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
472     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
473        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
474
475     Both are cited textually in the same manner: by using xref elements.
476     If you use the PI option, xml2rfc will, by default, try to find included files in the same
477     directory as the including file. You can also define the XML_LIBRARY environment variable
478     with a value containing a set of directories to search.  These can be either in the local
479     filing system or remote ones accessed by http (http://domain/dir/... ).-->
480    <references>
481      <name>References</name>
482      <references>
483        <name>Normative References</name>
484
485<xi:include
486    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
487<xi:include
488    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml"/>
489<xi:include
490    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml"/>
491<xi:include
492    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
493<xi:include
494    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml"/>
495<xi:include
496    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
497<xi:include
498    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
499
500        <reference anchor="SHA3" target="https://www.nist.gov/publications/sha-3-standard-permutation-based-hash-and-extendable-output-functions">
501          <front>
502            <title>SHA-3 Standard - Permutation-Based Hash and Extendable-Output Functions FIPS PUB 202</title>
503            <author>
504              <organization>National Institute of Standards and Technology (NIST)</organization>
505            </author>
506            <date month="August" year="2015"/>
507          </front>
508        </reference>
509      </references>
510
511      <references>
512        <name>Informative References</name>
513
514<xi:include
515    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml"/>
516<xi:include
517    href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml"/>
518
519        <reference anchor="SEC1" target="http://www.secg.org/sec1-v2.pdf">
520          <front>
521            <title>SEC 1: Elliptic Curve Cryptography</title>
522            <author>
523              <organization>Standards for Efficient Cryptography Group</organization>
524            </author>
525            <date month="May" year="2009"/>
526          </front>
527        </reference>
528        <reference anchor="X9.62">
529          <front>
530            <title>X9.62-2005: Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Standard (ECDSA)</title>
531            <author>
532              <organization>American National Standard for Financial Services (ANSI)</organization>
533            </author>
534            <date month="November" year="2005"/>
535          </front>
536        </reference>
537        <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">
538          <front>
539            <title>SP800-78-4: Cryptographic Algorithms and Key Sizes for Personal Identity Verification</title>
540            <author>
541              <organization>National Institute of Standards and Technology (NIST)</organization>
542            </author>
543            <date month="May" year="2014"/>
544          </front>
545        </reference>
546        <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">
547          <front>
548            <title>SMI Security for PKIX Algorithms</title>
549            <author>
550              <organization>IANA</organization>
551            </author>
552            <date month="March" year="2019"/>
553          </front>
554        </reference>
555        <reference anchor="Hash-Texts" target="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xhtml">
556          <front>
557            <title>Hash Function Textual Names</title>
558            <author>
559              <organization>IANA</organization>
560            </author>
561            <date month="July" year="2017"/>
562          </front>
563        </reference>
564        <reference anchor="SP800-107" target="https://csrc.nist.gov/csrc/media/publications/sp/800-107/rev-1/final/documents/draft_revised_sp800-107.pdf">
565          <front>
566            <title>SP800-107: Recommendation for Applications Using Approved Hash Algorithms</title>
567            <author>
568              <organization>National Institute of Standards and Technology (NIST)</organization>
569            </author>
570            <date month="May" year="2014"/>
571          </front>
572        </reference>
573        <!-- <reference anchor="SP800-90A" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-90Ar1.pdf">
574        <front>
575          <title>Recommendation for Random Number Generation Using Deterministic Random Bit Generators. NIST SP 800-90A</title>
576          <author>
577            <organization>National Institute of Standards and Technology</organization>
578          </author>
579          <date month="June" year="2015" />
580        </front>
581      </reference> -->
582        <!-- <reference anchor="SP800-185" target="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-185.pdf">
583        <front>
584          <title>SHA-3 Derived Functions: cSHAKE, KMAC, TupleHash and ParallelHash. NIST SP 800-185</title>
585          <author>
586            <organization>National Institute of Standards and Technology</organization>
587          </author>
588          <date month="December" year="2016" />
589        </front>
590      </reference> -->
591      </references>
592    </references>
593    <section anchor="asn" numbered="true" toc="default">
594      <name>ASN.1 module</name>
595      <t>This appendix includes the ASN.1 module for SHAKEs in X.509. 
596    This module does not come from any existing RFC. </t>
597      <sourcecode type="asn.1"><![CDATA[ 
598    PKIXAlgsForSHAKE-2019 { iso(1) identified-organization(3) dod(6)
599      internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
600      id-mod-pkix1-shakes-2019(TBD) }
601
602    DEFINITIONS EXPLICIT TAGS ::=
603
604    BEGIN
605
606    -- EXPORTS ALL;
607
608    IMPORTS
609
610    -- FROM RFC 5912
611
612    PUBLIC-KEY, SIGNATURE-ALGORITHM, DIGEST-ALGORITHM, SMIME-CAPS
613    FROM AlgorithmInformation-2009
614      { iso(1) identified-organization(3) dod(6) internet(1) security(5)
615        mechanisms(5) pkix(7) id-mod(0)
616        id-mod-algorithmInformation-02(58) }
617
618    -- FROM RFC 5912
619
620    RSAPublicKey, rsaEncryption, pk-rsa, pk-ec,
621    CURVE, id-ecPublicKey, ECPoint, ECParameters, ECDSA-Sig-Value
622    FROM PKIXAlgs-2009 { iso(1) identified-organization(3) dod(6)
623         internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
624         id-mod-pkix1-algorithms2008-02(56) }
625   ;
626
627    --
628    -- Message Digest Algorithms (mda-)
629    --
630    DigestAlgorithms DIGEST-ALGORITHM ::= {
631      -- This expands DigestAlgorithms from RFC 5912
632      mda-shake128   |
633      mda-shake256,
634      ...
635    }
636
637    --
638    -- One-Way Hash Functions
639    --
640
641    -- SHAKE128
642    mda-shake128 DIGEST-ALGORITHM ::= {
643      IDENTIFIER id-shake128  -- with output length 32 bytes.
644    }
645    id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
646                                        us(840) organization(1) gov(101)
647                                        csor(3) nistAlgorithm(4)
648                                        hashAlgs(2) 11 }
649
650    -- SHAKE256
651    mda-shake256 DIGEST-ALGORITHM ::= {
652      IDENTIFIER id-shake256  -- with output length 64 bytes.
653    }
654    id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16)
655                                        us(840) organization(1) gov(101)
656                                        csor(3) nistAlgorithm(4)
657                                        hashAlgs(2) 12 }
658
659    --
660    -- Public Key (pk-) Algorithms
661    --
662    PublicKeys PUBLIC-KEY ::= {
663      -- This expands PublicKeys from RFC 5912
664      pk-rsaSSA-PSS-SHAKE128 |
665      pk-rsaSSA-PSS-SHAKE256,
666      ...
667    }
668
669    -- The hashAlgorithm is mda-shake128
670    -- The maskGenAlgorithm is id-shake128
671    -- Mask Gen Algorithm is SHAKE128 with output length
672    -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 
673    -- modulus in bits.
674    -- The saltLength is 32. The trailerField is 1.
675    pk-rsaSSA-PSS-SHAKE128 PUBLIC-KEY ::= {
676      IDENTIFIER id-RSASSA-PSS-SHAKE128
677      KEY RSAPublicKey
678      PARAMS ARE absent
679      -- Private key format not in this module --
680      CERT-KEY-USAGE { nonRepudiation, digitalSignature,
681                       keyCertSign, cRLSign }
682    }
683
684    -- The hashAlgorithm is mda-shake256
685    -- The maskGenAlgorithm is id-shake256
686    -- Mask Gen Algorithm is SHAKE256 with output length
687    -- (8*ceil((n-1)/8) - 520)-bits, where n is the RSA 
688    -- modulus in bits.
689    -- The saltLength is 64. The trailerField is 1.
690    pk-rsaSSA-PSS-SHAKE256 PUBLIC-KEY ::= {
691      IDENTIFIER id-RSASSA-PSS-SHAKE256
692      KEY RSAPublicKey
693      PARAMS ARE absent
694      -- Private key format not in this module --
695      CERT-KEY-USAGE { nonRepudiation, digitalSignature,
696                       keyCertSign, cRLSign }
697    }
698
699    --
700    -- Signature Algorithms (sa-)
701    --
702    SignatureAlgs SIGNATURE-ALGORITHM ::= {
703      -- This expands SignatureAlgorithms from RFC 5912
704      sa-rsassapssWithSHAKE128 |
705      sa-rsassapssWithSHAKE256 |
706      sa-ecdsaWithSHAKE128 |
707      sa-ecdsaWithSHAKE256,
708      ...
709    }
710
711    --
712    -- SMIME Capabilities (sa-)
713    --
714    SMimeCaps SMIME-CAPS ::= {
715      -- The expands SMimeCaps from RFC 5912
716      sa-rsassapssWithSHAKE128.&smimeCaps |
717      sa-rsassapssWithSHAKE256.&smimeCaps |
718      sa-ecdsaWithSHAKE128.&smimeCaps |
719      sa-ecdsaWithSHAKE256.&smimeCaps,
720      ...
721    }
722
723    -- RSASSA-PSS with SHAKE128
724    sa-rsassapssWithSHAKE128 SIGNATURE-ALGORITHM ::= {
725      IDENTIFIER id-RSASSA-PSS-SHAKE128
726      PARAMS ARE absent
727          -- The hashAlgorithm is mda-shake128
728          -- The maskGenAlgorithm is id-shake128
729          -- Mask Gen Algorithm is SHAKE128 with output length
730          -- (8*ceil((n-1)/8) - 264) bits, where n is the RSA 
731          -- modulus in bits.
732          -- The saltLength is 32. The trailerField is 1
733      HASHES { mda-shake128 }
734      PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE128 }
735      SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE128 }
736    }
737    id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { iso(1) 
738            identified-organization(3) dod(6) internet(1) 
739            security(5) mechanisms(5) pkix(7) algorithms(6)
740            TBD1 }
741
742    -- RSASSA-PSS with SHAKE256
743    sa-rsassapssWithSHAKE256 SIGNATURE-ALGORITHM ::= {
744      IDENTIFIER id-RSASSA-PSS-SHAKE256
745      PARAMS ARE absent
746          -- The hashAlgorithm is mda-shake256
747          -- The maskGenAlgorithm is id-shake256
748          -- Mask Gen Algorithm is SHAKE256 with output length
749          -- (8*ceil((n-1)/8) - 520)-bits, where n is the 
750          -- RSA modulus in bits.
751          -- The saltLength is 64. The trailerField is 1.
752     HASHES { mda-shake256 }
753     PUBLIC-KEYS { pk-rsa | pk-rsaSSA-PSS-SHAKE256 }
754     SMIME-CAPS { IDENTIFIED BY id-RSASSA-PSS-SHAKE256 }
755    }
756    id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { iso(1) 
757            identified-organization(3) dod(6) internet(1) 
758            security(5) mechanisms(5) pkix(7) algorithms(6)
759            TBD2 }
760
761    -- ECDSA with SHAKE128
762    sa-ecdsaWithSHAKE128 SIGNATURE-ALGORITHM ::= {
763      IDENTIFIER id-ecdsa-with-shake128
764      VALUE ECDSA-Sig-Value
765      PARAMS ARE absent
766      HASHES { mda-shake128 }
767      PUBLIC-KEYS { pk-ec }
768      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake128 }
769    }
770    id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { iso(1) 
771            identified-organization(3) dod(6) internet(1) 
772            security(5) mechanisms(5) pkix(7) algorithms(6)
773            TBD3 } 
774
775    -- ECDSA with SHAKE256
776    sa-ecdsaWithSHAKE256 SIGNATURE-ALGORITHM ::= {
777      IDENTIFIER id-ecdsa-with-shake256
778      VALUE ECDSA-Sig-Value
779      PARAMS ARE absent
780      HASHES { mda-shake256 }
781      PUBLIC-KEYS { pk-ec }
782      SMIME-CAPS { IDENTIFIED BY id-ecdsa-with-shake256 }
783    }
784    id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { iso(1) 
785            identified-organization(3) dod(6) internet(1) 
786            security(5) mechanisms(5) pkix(7) algorithms(6)
787            TBD4 }
788
789    END
790 ]]></sourcecode>
791    </section>
792  </back>
793</rfc>
1<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
2<front>
3<title>Key words for use in RFCs to Indicate Requirement Levels</title>
4<author initials="S." surname="Bradner" fullname="S. Bradner"><organization/></author>
5<date year="1997" month="March"/>
6<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="2119"/>
10<seriesInfo name="DOI" value="10.17487/RFC2119"/>
11</reference>
1<reference anchor="RFC3279" target="https://www.rfc-editor.org/info/rfc3279" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3279.xml">
2<front>
3<title>Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="L." surname="Bassham" fullname="L. Bassham"><organization/></author>
5<author initials="W." surname="Polk" fullname="W. Polk"><organization/></author>
6<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
7<date year="2002" month="April"/>
8<abstract><t>This document specifies algorithm identifiers and ASN.1 encoding formats for digital signatures and subject public keys used in the Internet X.509 Public Key Infrastructure (PKI).  Digital signatures are used to sign certificates and certificate revocation list (CRLs).  Certificates include the public key of the named subject.  [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name="RFC" value="3279"/>
11<seriesInfo name="DOI" value="10.17487/RFC3279"/>
12</reference>
1<reference anchor="RFC4055" target="https://www.rfc-editor.org/info/rfc4055" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4055.xml">
2<front>
3<title>Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author>
5<author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author>
6<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
7<date year="2005" month="June"/>
8<abstract><t>This document supplements RFC 3279.  It describes the conventions for using the RSA Probabilistic Signature Scheme (RSASSA-PSS) signature algorithm, the RSA Encryption Scheme - Optimal Asymmetric Encryption Padding (RSAES-OAEP) key transport algorithm and additional one-way hash functions with the Public-Key Cryptography Standards (PKCS) #1 version 1.5 signature algorithm in the Internet X.509 Public Key Infrastructure (PKI).  Encoding formats, algorithm identifiers, and parameter formats are specified.  [STANDARDS-TRACK]</t></abstract>
9</front>
10<seriesInfo name="RFC" value="4055"/>
11<seriesInfo name="DOI" value="10.17487/RFC4055"/>
12</reference>
1<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5280" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml">
2<front>
3<title>Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile</title>
4<author initials="D." surname="Cooper" fullname="D. Cooper"><organization/></author>
5<author initials="S." surname="Santesson" fullname="S. Santesson"><organization/></author>
6<author initials="S." surname="Farrell" fullname="S. Farrell"><organization/></author>
7<author initials="S." surname="Boeyen" fullname="S. Boeyen"><organization/></author>
8<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
9<author initials="W." surname="Polk" fullname="W. Polk"><organization/></author>
10<date year="2008" month="May"/>
11<abstract><t>This memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet.  An overview of this approach and model is provided as an introduction.  The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms.  Standard certificate extensions are described and two Internet-specific extensions are defined.  A set of required certificate extensions is specified.  The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions.  An algorithm for X.509 certification path validation is described.  An ASN.1 module and examples are provided in the appendices.  [STANDARDS-TRACK]</t></abstract>
12</front>
13<seriesInfo name="RFC" value="5280"/>
14<seriesInfo name="DOI" value="10.17487/RFC5280"/>
15</reference>
1<reference anchor="RFC5480" target="https://www.rfc-editor.org/info/rfc5480" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5480.xml">
2<front>
3<title>Elliptic Curve Cryptography Subject Public Key Information</title>
4<author initials="S." surname="Turner" fullname="S. Turner"><organization/></author>
5<author initials="D." surname="Brown" fullname="D. Brown"><organization/></author>
6<author initials="K." surname="Yiu" fullname="K. Yiu"><organization/></author>
7<author initials="R." surname="Housley" fullname="R. Housley"><organization/></author>
8<author initials="T." surname="Polk" fullname="T. Polk"><organization/></author>
9<date year="2009" month="March"/>
10<abstract><t>This document specifies the syntax and semantics for the Subject Public Key Information field in certificates that support Elliptic Curve Cryptography.  This document updates Sections 2.3.5 and 5, and the ASN.1 module of "Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3279.  [STANDARDS-TRACK]</t></abstract>
11</front>
12<seriesInfo name="RFC" value="5480"/>
13<seriesInfo name="DOI" value="10.17487/RFC5480"/>
14</reference>
1<reference anchor="RFC8017" target="https://www.rfc-editor.org/info/rfc8017" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml">
2<front>
3<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
4<author initials="K." surname="Moriarty" fullname="K. Moriarty" role="editor"><organization/></author>
5<author initials="B." surname="Kaliski" fullname="B. Kaliski"><organization/></author>
6<author initials="J." surname="Jonsson" fullname="J. Jonsson"><organization/></author>
7<author initials="A." surname="Rusch" fullname="A. Rusch"><organization/></author>
8<date year="2016" month="November"/>
9<abstract><t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t><t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series.  By publishing this RFC, change control is transferred to the IETF.</t><t>This document also obsoletes RFC 3447.</t></abstract>
10</front>
11<seriesInfo name="RFC" value="8017"/>
12<seriesInfo name="DOI" value="10.17487/RFC8017"/>
13</reference>
1<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
2<front>
3<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
4<author initials="B." surname="Leiba" fullname="B. Leiba"><organization/></author>
5<date year="2017" month="May"/>
6<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
7</front>
8<seriesInfo name="BCP" value="14"/>
9<seriesInfo name="RFC" value="8174"/>
10<seriesInfo name="DOI" value="10.17487/RFC8174"/>
11</reference>
1<reference anchor="RFC5912" target="https://www.rfc-editor.org/info/rfc5912" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5912.xml">
2<front>
3<title>New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)</title>
4<author initials="P." surname="Hoffman" fullname="P. Hoffman"><organization/></author>
5<author initials="J." surname="Schaad" fullname="J. Schaad"><organization/></author>
6<date year="2010" month="June"/>
7<abstract><t>The Public Key Infrastructure using X.509 (PKIX) certificate format, and many associated formats, are expressed using ASN.1.  The current ASN.1 modules conform to the 1988 version of ASN.1.  This document updates those ASN.1 modules to conform to the 2002 version of ASN.1. There are no bits-on-the-wire changes to any of the formats; this is simply a change to the syntax.  This document is not an Internet  Standards Track specification; it is published for informational  purposes.</t></abstract>
8</front>
9<seriesInfo name="RFC" value="5912"/>
10<seriesInfo name="DOI" value="10.17487/RFC5912"/>
11</reference>
1<reference anchor="RFC6979" target="https://www.rfc-editor.org/info/rfc6979" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6979.xml">
2<front>
3<title>Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)</title>
4<author initials="T." surname="Pornin" fullname="T. Pornin"><organization/></author>
5<date year="2013" month="August"/>
6<abstract><t>This document defines a deterministic digital signature generation procedure.  Such signatures are compatible with standard Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA) digital signatures and can be processed with unmodified verifiers, which need not be aware of the procedure described therein.  Deterministic signatures retain the cryptographic security features associated with digital signatures but can be more easily implemented in various environments, since they do not need access to a source of high-quality randomness.</t></abstract>
7</front>
8<seriesInfo name="RFC" value="6979"/>
9<seriesInfo name="DOI" value="10.17487/RFC6979"/>
10</reference>

mirror server hosted at Truenetwork, Russian Federation.