draft-massimo-lamps-pq-sig-certificates-00.xml

<?xml version='1.0' encoding='utf-8'?>
<!-- This template is for creating an Internet Draft using xml2rfc,
    which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
    please see http://xml.resource.org/authoring/README.html. -->
<rfc
      xmlns:xi="http://www.w3.org/2001/XInclude"
      category="std"
      consensus="true"
      docName="draft-massimo-lamps-pq-sig-certificates-00"
      ipr="trust200902"
      obsoletes=""
      updates=""
      submissionType="IETF"
      xml:lang="en"
      tocInclude="true"
      tocDepth="4"
      symRefs="true"
      sortRefs="true"
      version="3">
  <!-- xml2rfc v2v3 conversion 2.38.1 -->
  <!-- category values: std, bcp, info, exp, and historic
    ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
       or pre5378Trust200902
    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="PQC SIG for Certificates">Algorithms and Identifiers for Post-Quantum Algorithms <br/> in the Internet X.509 Public Key Infrastructure</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-massimo-lamps-pq-pkix-00"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <author fullname="Jake Massimo" initials="J." surname="Massimo">
      <organization>AWS</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
          <region/>
          <code/>
          <country>USA</country>
        </postal>
        <email>jakemas@amazon.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Panos Kampanakis" initials="P." surname="Kampanakis">
      <organization>AWS</organization>
      <address>
        <postal>
          <street/>
          <!-- Reorder these if your country does things differently -->
          <region/>
          <code/>
          <country>USA</country>
        </postal>
        <email>kpanos@amazon.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Sean Turner" initials="S." surname="Turner">
      <organization>sn3rd</organization>
      <address>
        <email>sean@sn3rd.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Bas Westerbaan" initials="B." surname="Westerbaan">
      <organization>Cloudflare</organization>
      <address>
        <email>bas@westerbaan.name</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2022"/>
    <!-- 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>Security</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>PQ Signatures, post-quantum X.509</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 search engine. -->

   <abstract>
      <t>Digital signatures are used within X.509 certificates, Certificate Revocation Lists (CRLs), and to sign messages. This document describes the conventions for using Dilithium quantum-resistant signatures in Internet X.509 certificates and certifiate revocation lists.  The conventions for the associated post-quantum signatures, subject public keys, and private key are also described.</t>
    </abstract>

    <note>
    <t>[EDNOTE: This draft is not expected to be finalized before the NIST PQC Project has standardized PQ algorithms. After NIST has standardized its first algorithms, this document will replace TBD, with the appropriate algorithms and parameters before proceeding to ratification. The algorithm Dilithium has been added as an example in this draft, to provide a more detailed illustration of the content - it by no means indicates its inclusion in the final version. This specification will use object identifiers for the new algorithms that are assigned by NIST, and will use placeholders until these are released.]</t>

    </note>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>

      <t>The US National Institute of Standards and Technology (NIST) Post-Quantum Cryptography (PQC) effort has defined quantum-resistant public key cryptographic algorithm standards <xref target="NIST-PQC" format="default"></xref>. This document specifies the use of these Post-Quantum public key algorithms with Public Key Infrastructure X.509 (PKIX) certificates and Certificate Revocation Lists (CRLs) using object identifiers algorithms assigned by NIST.</t>
      
      <t>This specification includes conventions for the signatureAlgorithm, signatureValue, signature, and subjectPublicKeyInfo fields within Internet X.509 certificates and CRLs <xref target="RFC5280" format="default"></xref>, like <xref target="RFC3279" format="default"></xref> did for classic cryptography and <xref target="RFC5480" format="default"></xref> did for elliptic curve cryptography. It describes the encoding of digital signatures and public keys generated with quantum-resistant signature algorithm Dilithium.</t>

      <section numbered="true" toc="default">
        <name>Requirements Language</name>
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
       "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
       document are to be interpreted as described in BCP 14 <xref target="RFC2119" />
       <xref target="RFC8174" /> when, and only when, they appear in all capitals, as shown here.</t>
      </section> <!-- End of Requirements Language Section -->

    </section> <!-- End of Introduction Section -->


    <section numbered="true" toc="default" anchor="oids">
      <name>Identifiers</name>

      <t>This specification uses placeholders for object identifiers until the identifiers for the new algorithms are assigned by NIST.</t>
      
      <t>The AlgorithmIdentifier type, which is included herein for convenience, is defined as follows: </t>

       <sourcecode type="asn.1">
   AlgorithmIdentifier  ::=  SEQUENCE  {
       algorithm   OBJECT IDENTIFIER,
       parameters  ANY DEFINED BY algorithm OPTIONAL
   }
       </sourcecode>
       
       <aside>  
       <t>NOTE: The above syntax is from <xref target="RFC5280"/> and matches the version used therein, i.e., the 1988 ASN.1 syntax. See <xref target="RFC5912"/> for ASN.1 copmatible with the 2015 ASN.1 syntax.</t>
       </aside>

      <t>The OIDs are:</t>
      <sourcecode type="asn.1" markers="false" pn="section2-1">
   id-dilithiumTBD OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 
            country(16) us(840) organization(1) gov(101) csor(3) 
            nistAlgorithm(4) sigAlgs(3) TBD }  
      </sourcecode>
      
       <t>The contents of the parameters component for each algorithm are absent.</t>

    </section> <!-- End of Identifiers Section -->
        <section numbered="true" toc="default">
         <name>Dilithium Signatures in PKIX</name>
        
         <t>Dilithium is a digital signature scheme built upon the Fiat-Shamir-with-aborts framework <xref target="Fiat-Shamir" format="default"></xref>. The security is based upon the hardness of lattice problems over module lattices <xref target="Dilithium" format="default"></xref>. Dilithium provides three parameter sets for the security categories 2, 3 and 5.</t>

          <t>Signatures are used in a number of different ASN.1 structures.
          As shown in the ASN.1 representation from <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/> 
	below, in an X.509 certificate, a signature is encoded with an 
	algorithm identifier in the signatureAlgorithm attribute and 
	a signatureValue attribute that contains the actual signature.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.1-2">
   Certificate  ::=  SEQUENCE  {
      tbsCertificate       TBSCertificate,
      signatureAlgorithm   AlgorithmIdentifier,
      signatureValue       BIT STRING  }
        </sourcecode>

          <t>Signatures are also used in the CRL list ASN.1 representation from <xref target="RFC5280" format="default" sectionFormat="of" derivedContent="RFC5280"/>
        below. In a X.509 CRL, a signature is encoded with an
        algorithm identifier in the signatureAlgorithm attribute and
        a signatureValue attribute that contains the actual signature.</t>
        <sourcecode type="asn.1" markers="false" pn="section-4.1-3">
   CertificateList  ::=  SEQUENCE  {
      tbsCertificate       TBSCertList,
      signatureAlgorithm   AlgorithmIdentifier,
      signatureValue       BIT STRING  }
        </sourcecode>

        <t>The identifiers defined in <xref target="oids" format="default"/> can be used as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence Certificate/CertificateList and the signature field in the sequence TBSCertificate/TBSCertList in certificates CRLs, respectively, <xref target="RFC5280" format="default"/>. The parameters of these signature algorithms are absent, as explained in <xref target="oids" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>
        
        <t>The signatureValue field contains the corresponding Dilithium signature computed upon the ASN.1 DER encoded tbsCertificate <xref target="RFC5280" format="default"/>.</t>
        
        <t>Conforming Certification Authority (CA) implementations <bcp14>MUST</bcp14> specify the algorithms explicitly by using the OIDs specified in <xref target="oids" format="default" sectionFormat="of" derivedContent="Section 3"/> when encoding Dilithium signatures in certificates and CRLs. Conforming client implementations that process certificates and CRLs using Dilithium <bcp14>MUST</bcp14> recognize the corresponding OIDs. Encoding rules for Dilithium signature values are specified <xref target="oids" format="default" sectionFormat="of" derivedContent="Section 3"/>.</t>

          <t>When the id-dilithiumTBD identifier appears in the algorithm field as an AlgorithmIdentifier, the encoding <bcp14>MUST</bcp14> omit the parameters field. That is, the AlgorithmIdentifier <bcp14>SHALL</bcp14> be a SEQUENCE of one component, the OID id-dilithiumTBD.</t>
        </section> <!-- End of Dilithium Signatures in PKIX Section -->


         <!-- [PK] What is this section going to include? -->
         <!-- [JM] Should another algorithm be selected by NIST, we would include a summary of the algorithm, and then the ASN.1 definition and OIDs, just like we did for Dilithium above.-->
         <!-- [PK] I don't think we should do that. We should introduce one algorithm. Standardizing two without very obvious advantages is probably overhead for the whole industry. I think we should pick the one that makes sense. Commenting it out to similify draft. We can add it back. -->     
        <!--<section numbered="true" toc="default">
         <name>TBD Signature Algorithm</name>
         <t>TBD</t>
        </section> --> <!-- End of TBD Signature Algorithm Section -->

  
    <!-- [PK] Commenting out for now since we only need it if we introduce more than one algorithms --> 
    <!--<section anchor="subjectpublickey" numbered="true" toc="default">
    <name>Subject Public Key Fields</name> --> 
    
        <section anchor="dilithiumpublickey" numbered="true" toc="default">
         <name>Dilithium Public Keys in PKIX</name>
         
         <t>In the X.509 certificate, the subjectPublicKeyInfo field has the SubjectPublicKeyInfo type, which has the following ASN.1 syntax: </t>
        <sourcecode type="asn.1">
  SubjectPublicKeyInfo  ::=  SEQUENCE  {
      algorithm         AlgorithmIdentifier,
      subjectPublicKey  BIT STRING
  } 
  </sourcecode>
         
         <t>The public parameters for Dilithium are based upon a polynomial ring R_q for prime q. A (k*l) public matrix A is produced, consisting of polynomials whose coefficients are sampled uniformly at random from the integers modulo q. This sampling is performed by expanding a nonce (rho) using an XOF.</t> <!--- [JM]This could be too much detail (I think it is) but otherwise if feels like are plucking letters out of the air. I guess we pluck p and q out of the air in the original RSA/DH spec, but because there are so many more letters in Dilithium, it feels worse. This is the most brief of an explanation I could give for where rho, and k come from. --> 
         <!--- [EC]I found the sentence about "rho" very hard to read. Something like "expanding a nonce (rho) using..." could help. I also found the "(k*l) public matrix" hard to read because of how 'l' is rendered. It's also not referenced in this section anywhere (it doesn't affect the size of the public key??), but it does make an appearance in the appendix. -->
         <t>The Dilithium public key <bcp14>MUST</bcp14> be encoded using the ASN.1 type DilithiumPublicKey:</t>
         
                <!---<ul spacing="compact">
                    <li>rho: nonce</li>
                    <li>t:  a vector encoded in 320*k bytes</li>
                </ul>
                <t>The size required to hold all public key elements is therefore 32+320*k bytes, where k is the rank of the vector over the polynomial ring R_q.</t>
          -->
       <!--   
      <sourcecode type="asn.1" markers="false" pn="section">
  DilithiumPublicKey ::= SEQUENCE {
      rho         OCTET STRING,      nonce/seed
      t1          OCTET STRING  }    encoded vector 
      </sourcecode> 
      <t>where rho is the nonce used to seed the XOF to produce the matrix A, and t1 is a vector encoded in 320*k bytes where k is the rank of the vector over the polynomial ring R_q. The size required to hold all public key elements is therefore 32+320*k bytes.</t>
        -->
        <!--[JM] I've modified the public key encoding based on Markku's comments from pqc-forum (https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/eAaiJO1qzkA/m/4eclSTZbBwAJ). On the use of a sequence tag, and separation bytes:

        "The "internal" separator bytes break verification unless both signer and verifier just implement a weakened hash-and-sign mode (or if the signer always adds the same non-standard padding bytes, or if a re-serialization step is implemented for hash computation.) Note that the additional encoding is unnecessary for X.509 interoperability; in addition to OID, the entire public key can be encoded as a single OCTET STRING (as the standard encoding is unambiguous); this also results in a 10-byte saving in certificate length."

        This is part of the discussion for Dilithium's security property of non-repudiation.
         -->
         
       <sourcecode type="asn.1" markers="false" pn="section">
  DilithiumPublicKey ::= OCTET STRING
      </sourcecode> 
         <t>where DilithiumPublicKey is a concatenation of rho and t1. Here, rho is the nonce used to seed the XOF to produce the matrix A, and t1 is a vector encoded in 320*k bytes where k is the rank of the vector over the polynomial ring R_q. These parameters <bcp14>MUST</bcp14> be encoded as a single OCTET STRING. The size required to hold a DilithiumPublicKey public key element is therefore 32+320*k bytes.</t>

          <!-- do we need to include this? I'm basing this on the original RFC 3279 which did this for ECC https://datatracker.ietf.org/doc/html/rfc3279#section-2.3.3-->
        <!-- [PK] In the past using parameters in OIDs have caused all types of issues. Nowadays the IETF hardcodes all parameters to the OID. For example OID XYZ gives everything needed for the algorithm like security level, hash algorithm key sizes etc. --> 
        <!-- <t>Dilithium requires the use of certain parameters with the public key. The parameters may be inherited from the issuer, implicitly included through reference to a "security level", or explicitly included in the certificate.</t>
      <sourcecode type="asn.1" markers="false" pn="section-4">
  DilithiumPkParameters ::= CHOICE {
    dilithiumParameters  DilithiumParameters,
    securityLevel        OBJECT IDENTIFIER,
    implicitlyCA         NULL } 
      </sourcecode> 
      <t>EDNOTE: security level is used analogously to how "named-curves" was used in ECDSA and ECDH keys, alternatively, this same distinction between parameter sets could be achieved by instead defining multiple dilithium OIDs based on security level. e.g. id-dilithium-3-shake256 or id-dilithium-4x4-shake256.</t>
      <t>The object identifier id-securityLevel specifies an arc containing the object identifiers of each security level.  It has the following value:</t>     
               <artwork name="" type="" align="left" alt=""><![CDATA[
id-securityLevel OBJECT IDENTIFIER ::= { XXXX-XX-XX securityLevel(X) }]]>
                </artwork> 
      <t> When the parameters are inherited, the parameters field <bcp14>SHALL</bcp14> contain implictlyCA, which is the ASN.1 value NULL. When parameters are specified by reference, the parameters field <bcp14>SHALL</bcp14> contain the security level choice, which is an object identifier.  When the parameters are explicitly included, they <bcp14>SHALL</bcp14> be encoded in the ASN.1 structure DilithiumParameters:</t>
      <sourcecode type="asn.1" markers="false" pn="section-5">
  DilithiumParameters ::= SEQUENCE {
      n        INTEGER,    the dimension of the polynomial ring R_q
      q        INTEGER,    the modulus of the polynomial ring R_q
      k        INTEGER,    rank of the vector over R_q
      l        INTEGER,    rank of the vector over R_q
      eta      INTEGER,    bound on size of the coefficients for keygen
      gamma1   INTEGER,    bound on size of coefficients for signing
      gamma2   INTEGER,    bound on size of coefficients for signing
      beta     INTEGER,    the reduction in the bound for verification
      }
      </sourcecode> -->
<!-- EDNOTE: I dont know what data type all those variables should be, between integers, octet strings or bit strings. could also break them out even further into more objects -->

         <!-- [PK]: Commenting out as I think this goes back to the hardcoded parameters and is unecessary --> 
         <!--<t>The AlgorithmIdentifier within SubjectPublicKeyInfo is the only place within a certificate where the parameters may be used. If the Dilithium parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the subject certificate using Dilithium, then the certificate issuer's Dilithium parameters apply to the subject's Dilithium key. If the Dilithium  parameters are specified as implicitlyCA in the SubjectPublicKeyInfo AlgorithmIdentifier and the CA signed the certificate using a signature algorithm other than Dilithium, then clients <bcp14>MUST</bcp14> not make use of the Dilithium public key.</t>-->

         <t>The id-dilithiumTBD identifier defined in <xref target="oids"/> <bcp14>MUST</bcp14> be used as the algorithm field in the SubjectPublicKeyInfo sequence <xref target="RFC5280" format="default"/> to identify a Dilithium public key.</t>
         
         <t>The intended application for the key is indicated in the keyUsage certificate extension; see <xref target="RFC5280" sectionFormat="of" section="4.2.1.3"/>. If the keyUsage extension is present in a certificate that indicates id-dilithiumTBD in the SubjectPublicKeyInfo, then the at least one of following <bcp14>MUST</bcp14> be present:</t>
<artwork><![CDATA[
  digitalSignature; or
  nonRepudiation; or
  keyCertSign; or
  cRLSign.
]]></artwork>
         <t>Requirements about the keyUsage extension bits defined in <xref target="RFC5280" format="default"/> still apply.</t>
         
         <t>Conforming CA implementations <bcp14>MUST</bcp14> specify the X.509 public key algorithm explicitly by using the OIDs specified in <xref target="oids"/> when using Dilithium public keys in certificates and CRLs. Conforming client implementations that process Dilithium public keys when processing certificates and CRLs <bcp14>MUST</bcp14> recognize the corresponding OIDs. </t>

        </section>  <!-- End of Dilithium Public Keys in PKIX Section -->

         <!-- [PK] What is this section going to include? -->
         <!-- [JM] Say NIST standardize both Dilithium and falcon, then this section would describe falcons public keys, just as we did for Dilithium above. -->
         <!-- [PK] I don't think we should do that. We should introduce one algorithm. Standardizing two without very obvious advantages is probably overhead for the whole industry. I think we should pick the one that makes sense. Commenting it out to similify draft. We can add it back. -->      
        <!-- <section numbered="true" toc="default">
         <name>TBD Public Keys</name> 
         <t>TBD</t>
        </section> -->  <!-- End of TBD Public Keys Section -->
        
    <!--</section>--> <!-- End of Subject Public Key Fields Section -->


    <!-- [PK] Commenting out for now since we only need it if we introduce more than one algorithms --> 
    <!-- <section anchor="privatekeyformat" numbered="true" toc="default">
    <name>Private Key Format</name> -->
    
    <!-- [PK] In the other drafts that update RFC3279 I did not see them including a Private Key format for any of the algorithms. Do we need a private key section for Dilithium? Encoding private keys is useful to the signer, but does this specification need to define it? Usually these would be defined elsewhere. Commenting Private Key section for now, and I will let JK bring it back if he thinks it should be there.  -->     
        <section numbered="true" toc="default">
         <name>Dilithium Private Keys</name>
         <t>A Dilithium private key is encoded as DilithiumPrivateKey in the privateKey field as an OCTET STRING. Dilithium public keys are optionally distributed in the publicKey field of the DilithiumPrivateKey structure.</t>
         <t>The ASN.1 encoding for a Dilithium private key is as follows:</t>
      <sourcecode type="asn.1" markers="false" pn="section-7">
  DilithiumPrivateKey ::= SEQUENCE {
      rho         BIT STRING,         - nonce/seed
      K           BIT STRING,         - key/seed
      tr          BIT STRING,         - PRF bytes (CRH in spec.)
      s1          BIT STRING,         - vector l
      s2          BIT STRING,         - vector k
      t0          BIT STRING,         - encoded vector
      PublicKey   IMPLICIT DilithiumPublicKey OPTIONAL
  }
      </sourcecode> 
                <!-- [JM] I'm unsure if BIT STRING is the correct data type here. Please confirm or suggest alt. -->
                <!--[JM] deterministic vs random signatures, see https://pq-crystals.org/dilithium/data/dilithium-specification-round3.pdf page 13 caption of figure 4 -->
                <t>Dilithium offers both deterministic and randomized signing. The deterministic version creates a signature based on a function of the key K and the message, whereas the randomized version instead selects these values at random. The randomized version can be invoked by leaving K as EMPTY.</t>

                <t>A fully populated Dilithium private key consists of 6 parameters. The size necessary to hold all private key elements is 32+32+32+32*[(k+l)*ceiling(log(2*eta+1))+13*k] bytes. The description of k, l, and eta as well as public key and secret key sizes for security levels 2, 3, and 5 can be found in Figure 1 of the Appendix.</t>

                <!-- [JM] section under construction. Do we need a basic description of each private key parameter? I think a breif overview (as we did for the public key would be nice to have.-->

          </section>  <!-- End of Dilithium Private Keys Section -->

         <!-- [PK] What is this section going to include? -->
         <!-- [JM] Say NIST standardize both Dilithium and falcon, then this section would describe falcons private keys, just as we did for Dilithium above. -->  
         <!-- [PK] I don't think we should do that. We should introduce one algorithm. Standardizing two without very obvious advantages is probably overhead for the whole industry. I think we should pick the one that makes sense. Commenting it out to similify draft. We can add it back. -->         
        <!--<section numbered="true" toc="default">
          <name>TBD Private Keys</name>
          <t>TBD</t>
        </section> -->  <!-- End of TBD Private Keys Section -->
        
    <!--</section> End of Private Key Format Section -->
    

<!-- [JM] I've taken a stab at the ASN.1 module based on the guidance in https://www.rfc-editor.org/rfc/rfc5912.txt and the example in https://datatracker.ietf.org/doc/html/rfc8692. This should be treated as a rough draft and will require some checking.-->   
    <section anchor="asn1" numbered="true" toc="default">
      <name>ASN.1 Module</name>
      <t>This section includes the ASN.1 module for Post-Quantum algorithms in X.509. This module does not come from any previously existing RFC. This module references <xref target="RFC5912" format="default"></xref>.</t>
      <sourcecode type="asn.1" markers="false" pn="section-6">
[ EDNOTE: Add ASN.1 here ] 

  PKIX1-PQ-Algorithms { iso(1) identified-organization(3) dod(6)
     internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
     id-mod-pkix1-PQ-algorithms(X) }

  DEFINITIONS EXPLICIT TAGS ::=

  BEGIN

  -- EXPORTS ALL;

  IMPORTS

  -- FROM 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) }

  --
  -- Public Key (pk-) Algorithms
  --
  PublicKeys PUBLIC-KEY ::= {
    -- This expands PublicKeys from RFC 5912
    pk-dilithiumTBD |
    pk-TBD-TBD,
    ...
  }

  -- The hashAlgorithm is mda-shake256
  -- The XOF seed rho is 32 bytes
  -- The vector t1 is 320*k bytes
  -- These are encoded as a single string
  pk-dilithiumTBD PUBLIC-KEY ::= {
    IDENTIFIER id-dilithiumTBD
    KEY DilithiumPublicKey
    PARAMS ARE absent
    CERT-KEY-USAGE { nonRepudiation, digitalSignature,
                    keyCertSign, cRLSign }
    PRIVATE-KEY DilithiumPrivateKey
  }

  END
  </sourcecode> 

   </section>     <!-- End of ASN.1 Module Section -->
    
  
   <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>Extensions in certificates and CRLs are identified using object Identifiers (OIDs). The creation and delegation of these arcs is to be determined.</t>
      
      <t>IANA is requested to register the id-mod-pkix1-PQ-algorithms OID for the ASN.1 module identifier found in Section 5 in the "SMI Security for PKIX Module Identifier" registry.</t>
    </section>  <!-- End of IANA Considerations Section -->
    
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>The Security Considerations section of <xref target="RFC5280" format="default"></xref> applies to this specification as well.</t>

      <!-- [JM] how deep should we go on EUF-CMA security? I don't really want to get into "games" here -->
      <!-- [PK] Not necessary. Just this paragraph is fine, if that.  -->
      <t>The digital signature scheme <!--note remove plural if only one--> defined within this document are modeled under existentially unforgeable digital signatures with respect to an adaptive chosen message attack (EUF-CMA). For the purpose of estimating security strength, it has been assumed that the attacker has access to signatures for no more than 2^{64} chosen messages.</t>

      <!--<t>TODO: Add discussion about digests in classical signatures hash-then-sign and how that does not apply to PQ like Dilithium. And how committing to a message is additional security. Reference NIST discussion from Peiker and Makku.</t>-->
      <t>EDNOTE: Discuss implications of not hash-then-sign. Implications in performance too.</t>
      <!-- [JM] Small note on hash-then-sign. Dilithium (see fig 4 line 10 of https://pq-crystals.org/dilithium/data/dilithium-specification-round3.pdf) " Our full scheme in Fig. 4 also makes use of basic optimizations such as pre-hashing the message M so as to not rehash it with every signing attempt." -->
      <t>Within the hash-then-sign paradigm, hash functions are used as a domain restrictor over the message to be signed. By pre-hashing, the onus of resistance to existential forgeries becomes heavily reliant on the collision-resistance of the hash function in use. As well as this security goal, the hash-then-sign paradigm also has the ability to improve performance by reducing the size of signed messages. As a corollary, hashing remains mandatory even for short messages and assigns a further computational requirement onto the verifier. This makes the performance of hash-then-sign schemes more consistent, but not necessarily more efficient. Dilithium diverges from the hash-then-sign paradigm by hashing the message
      <!-- [EC] Something is wrong with "(at the point in which the challenge polynomial)"  -->
      during the signing procedure (at the point in which the challenge polynomial). However, due to the fact that Dilithium signatures may require the signing procedure to be repeated several times for a signature to be produced, Dilithium implementations can make use of pre-hashing the message to prevent rehashing with each attempt.</t>

      <t>EDNOTE: Discuss side-channels for Dilithium. .</t>
      <t>Dilithium has been designed to provide side-channel resilience by eliminating a reliance on Gaussian sampling. While deliberate design decisions such as these can help to deliver a greater ease of secure implementation - particularly against side-channel attacks - it does not necessarily provide resistance to more powerful attacks such as differential power analysis. Some amount of side-channel leakage has been demonstrated in parts of the signing algorithm (specifically the bit-unpacking function), from which a demonstration of key recovery has been made over a large sample of signatures. Masking countermeasures exist for Dilithium<!--[MGTF19]-->, but come with a performance overhead.</t>

      <t>A fundamental security property also associated with digital signatures is non-repudiation. Non-repudiation refers to the assurance that the owner of a signature key pair that was capable of generating an existing signature corresponding to certain data cannot convincingly deny having signed the data. The digital signature scheme Dilithium possess three security properties beyond unforgeability, that are associated with non-repudiation. These are exclusive ownership, message-bound signatures, and non-resignability. These properties are based tightly on the assumed collision resistance of the hash function used (in this case SHAKE-256).

      Exclusive ownership is a property in which a signature sigma uniquely determines the public key and message for which it is valid. Message-bound signatures is the property that a valid signature uniquely determines the message for which it is valid, but not necessarily the public key. Non-resignability is the property in which one cannot produce a valid signature under another key given a signature sigma for some unknown message m. These properties are not provided by classical signature schemes such as DSA or ECDSA, and have led to a variety of attacks such as Duplicate-Signature Key Selection (DSKS) attacks <!--[BWM99, MS04]-->, and attacks on the protocols for secure routing<!--[JCCS19]-->. A full discussion of these properties in Dilithium can be found at <xref target="CDFFJ21" format="default"></xref>.

      These properties are dependent, in part, on unambiguous public key serialization. It for this reason the public key structure defined in <xref target="dilithiumpublickey" format="default"/> is intentionally encoded as a single OCTET STRING.</t>


    </section>  <!-- End of Security Considerations 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"?-->
          <?rfc include="reference.RFC.2119.xml"?>
          <!--<?rfc include="reference.RFC.4055.xml"?>-->
          <?rfc include="reference.RFC.5280.xml"?>
          <?rfc include="reference.RFC.5912.xml"?>
          <!--<?rfc include="reference.RFC.5480.xml"?>-->
          <?rfc include="reference.RFC.8174.xml"?>

     <reference anchor="NIST-PQC" target="https://csrc.nist.gov/Projects/post-quantum-cryptography/post-quantum-cryptography-standardization/Call-for-Proposals">
          <front>
            <title>Post-Quantum Cryptography</title>
            <author initials="" surname="National Institute of Standards and Technology (NIST)" fullname="">
              <organization/>
            </author>
            <date year="2016"/>
          </front>
        </reference>

      <!-- 
      <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf">
          <front>
            <title>SHA-3 Standard: Permutation-Based Hash and Extendable Output Functions</title>
            <author initials="" surname="National Institute of Standards and Technology (NIST)" fullname="">
              <organization/>
            </author>
            <date year="2015" month="August"/>
          </front>
        </reference>
      -->
      </references>
      <references>
        <name>Informative References</name>
          <?rfc include="reference.RFC.3279.xml"?>
          <?rfc include="reference.RFC.5480.xml"?>

     <reference anchor="Dilithium" target="https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf">
          <front>
            <title>CRYSTALS-Dilithium Algorithm Specifications and Supporting Documentation</title>
            <author initials="S." surname="Bai" fullname="S. Bai">
            </author>
            <author initials="L." surname="Ducas" fullname="L. Ducas">
            </author>
            <author initials="T." surname="Lepoint" fullname="T. Lepoint">
            </author>
            <author initials="V." surname="Lyubashevsky" fullname="V. Lyubashevsky">
            </author>
            <author initials="P." surname="Schwabe" fullname="P. Schwabe">
            </author>
            <author initials="G." surname="Seiler" fullname="G. Seiler">
            </author>
            <author initials="D." surname="Stehlé" fullname="D. Stehlé">
            </author>
            <date year="2021"/>
          </front>
        </reference>

        <reference anchor="Fiat-Shamir" target="https://www.iacr.org/archive/asiacrypt2009/59120596/59120596.pdf">
          <front>
            <title>Fiat-Shamir with aborts: Applications to lattice and factoring-based signatures</title>
            <author initials="V." surname="Lyubashevsky" fullname="V. Lyubashevsky">
            </author>
            <date year="2009"/>
          </front>
          <refcontent>International Conference on the Theory and Application of Cryptology and Information Security</refcontent>
        </reference>

        <reference anchor="CDFFJ21" target="https://eprint.iacr.org/2020/1525.pdf">
          <front>
            <title>BUFFing signature schemes beyond unforgeability and the case of post-quantum signatures</title>
            <author initials="Cas" surname="Cremers" fullname="C. Cremers">
            </author>
            <author initials="S." surname="Düzlü" fullname="S. Düzlü">
            </author>
            <author initials="R." surname="Fiedler" fullname="R. Fiedler">
            </author>
            <author initials="M." surname="Fischlin" fullname="M. Fischlin">
            </author>
            <author initials="C." surname="Janson" fullname="C. Janson">
            </author>
            <date year="2021"/>
          </front>
        <refcontent>In Proceedings of the 42nd IEEE Symposium on Security and Privacy</refcontent>
        </reference>

  

        <!--
      <reference anchor="draft-truskovsky-lamps-pq-hybrid-x509-01" target="https://datatracker.ietf.org/doc/html/draft-truskovsky-lamps-pq-hybrid-x509-01">
          <front>
            <title>Multiple Public-Key Algorithm X.509 Certificates</title>
            <author initials="A." surname="Truskovsky" fullname="A. Truskovsky">
            </author>
            <author initials="D." surname="Van Geest" fullname="D. Van Geest">
            </author>
            <author initials="S." surname="Fluhrer" fullname="S. Fluhrer">
            </author>
            <author initials="P." surname="Kampanakis" fullname="P. Kampanakis">
            </author>
            <author initials="M." surname="Ounsworth" fullname="M. Ounsworth">
            </author>
            <author initials="S." surname="Mister" fullname="S. Mister">
            </author>
            <date year="2018" month="August"/>
          </front>
        </reference>
    -->
      </references>
    </references>  <!-- End of References -->

    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>We would like to thank ... <!--Markuu, Peikert -->for their insightful comments.</t>
    </section>  <!-- End of Acknowledgements Section -->    

    <section anchor="app-additional" numbered="true" toc="default">
      <name>Appendix</name>
      
        <t>Instead of defining the strength of a quantum algorithm in a traditional manner using precise estimates of the number of bits of security, NIST has instead elected to define a collection of broad security strength categories. Each category is defined by a comparatively easy-to-analyze reference primitive that cover a range of security strengths offered by existing NIST standards in symmetric cryptography, which NIST expects to offer significant resistance to quantum cryptanalysis. These categories describe any attack that breaks the relevant security definition that must require computational resources comparable to or greater than those required for: Level 1 - key search on a block cipher with a 128-bit key (e.g., AES128), Level 2 - collision search on a 256-bit hash function (e.g., SHA256/ SHA3-256), Level 3 - key search on a block cipher with a 192-bit key (e.g., AES192), Level 4 - collision search on a 384-bit hash function (e.g. SHA384/ SHA3-384), Level 5 - key search on a block cipher with a 256-bit key (e.g., AES 256).</t>
      
        <t>The parameter sets defined for NIST security levels 2, 3 and 5 are listed in the Figure 1, along with the resulting public key and private key sizes in bytes.</t>
        <!-- full table, see page 15 of https://pq-crystals.org/dilithium/data/dilithium-specification-round3-20210208.pdf -->
        <!-- [JM] we can consider the usefulness of this table/domain parameter discussion here, since we do not want to include the parameter selection in the document -->
        <figure anchor="DilithiumParameters">
          <artwork align="left" name="" type="" alt=""><![CDATA[
|==========+=====+=========+=======+=====+========+========+=========|
| Security |  n  |    q    | (k,l) | eta | gamma1 | Public | Private |
| Level    |     |         |       |     |        | Key(B) | Key(B)  |
|==========+=====+=========+=======+=====+========+========+=========|
| 2        | 256 | 8380417 | (4,4) |  2  |  2^17  |  1312  |   2528  | 
| 3        | 256 | 8380417 | (6,5) |  4  |  2^19  |  1952  |   4000  | 
| 5        | 256 | 8380417 | (8,7) |  2  |  2^19  |  2596  |   4864  |
|==========+=====+=========+=======+=====+========+========+=========|]]>
          </artwork>
        </figure>
    </section> <!-- End of Appendix Section -->
    
    <!-- Change Log

v00 2006-03-15  EBD   Initial version

v01 2006-04-03  EBD   Moved PI location back to position 1 -
                     v3.1 of XMLmind is better with them at this location.
v02 2007-03-07  AH    removed extraneous nested_list attribute,
                     other minor corrections
v03 2007-03-09  EBD   Added comments on null IANA sections and fixed heading capitalization.
                     Modified comments around figure to reflect non-implementation of
                     figure indent control.  Put in reference using anchor="DOMINATION".
                     Fixed up the date specification comments to reflect current truth.
v04 2007-03-09 AH     Major changes: shortened discussion of PIs,
                     added discussion of rfc include.
v05 2007-03-10 EBD    Added preamble to C program example to tell about ABNF and alternative 
                     images. Removed meta-characters from comments (causes problems).

v06 2010-04-01 TT     Changed ipr attribute values to latest ones. Changed date to
                     year only, to be consistent with the comments. Updated the 
                     IANA guidelines reference from the I-D to the finished RFC.
v07 2020-01-21 HL    Converted the template to use XML schema version 3.
    -->
 </back>
</rfc>