<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced. 
An alternate method (rfc include) is described in the references. -->

<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC8152 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8152.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-atkins-suit-cose-walnutdsa-07" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
       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="WalnutDSA COSE Sigs">Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and Encryption (COSE) </title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Derek Atkins" initials="D.A." surname="Atkins">
      <organization>Veridify Security</organization>

      <address>
        <postal>
          <street>100 Beard Sawmill Rd, Suite 350</street>
          <!-- Reorder these if your country does things differently -->
          <city>Shelton</city>
          <region>CT</region>
          <code>06484</code>
          <country>US</country>
        </postal>
        <phone>+1 617 623 3745</phone>
        <email>datkins@veridify.com</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date month="January" year="2021" />

    <!-- 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>Internet Engineering Task Force</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>COSE</keyword>
    <keyword>WalnutDSA</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>This document specifies the conventions for using the Walnut
      Digital Signature Algorithm (WalnutDSA) for digital signatures
      with the CBOR Object Signing and Encryption (COSE) syntax.
      WalnutDSA is a lightweight, quantum-resistant signature scheme
      based on Group Theoretic Cryptography <!-- (see <xref target="WALNUTDSA" />
      and <xref target="WALNUTSPEC" />) --> with implementation and
      computational efficiency of signature verification in constrained
      environments, even on 8- and 16-bit platforms.</t>

      <t>The goal of this publication is to document a way to use the
      lightweight, quantum-resistant WalnutDSA signature algorithm in
      COSE in a way that would allow multiple developers to build
      compatible implementations.  As of this publication, the
      security properties of WalnutDSA have not been evaluated by the
      IETF and its use has not been endorsed by the IETF.
      </t>

      <t>WalnutDSA(TM) and Walnut Digital Signature Algorithm(TM) are
      trademarks of Veridify Security Inc..</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document specifies the conventions for using the Walnut
      Digital Signature Algorithm (WalnutDSA) <xref target="WALNUTDSA"
      /> for digital signatures with the CBOR Object Signing and
      Encryption (COSE) <xref target="RFC8152" /> syntax.  WalnutDSA
      is a Group-Theoretic <xref target="GTC" /> signature scheme
      where signature validation is both computationally- and
      space-efficient, even on very small processors.  Unlike many
      hash-based signatures, there is no state required and no limit
      on the number of signatures that can be made.  WalnutDSA private
      and public keys are relatively small; however, the signatures
      are larger than RSA and ECC, but still smaller than most all
      other quantum-resistant schemes (including all hash-based
      schemes).</t>

      <t>COSE provides a lightweight method to encode structured data.
      WalnutDSA is a lightweight, quantum-resistant digital
      signature algorithm.  The goal of this specification is to
      document a method to leverage WalnutDSA in COSE in a way that
      would allow multiple developers to build compatible
      implementations.</t>

      <t>As with all cryptosystems, the initial versions of WalnutDSA
      underwent significant cryptanalysis, and in some cases,
      identified potential issues. For more discussion on this topic,
      a summary of all published cryptanalysis can be found in Section
      5.2. Validated issues were addressed by reparameterization in
      updated versions of WalnutDSA.  Although the IETF has neither
      evaluated the security properties of WalnutDSA nor has the IETF
      endorsed WalnutDSA as of this publication, this document
      provides a method to use WalnutDSA in conjunction with IETF
      protocols.  As always, users of any security algorithm are
      advised to research the security properties of the algorithm and
      make their own judgment about the risks involved.</t>

      <section title="Motivation">
	<t>Recent advances in cryptanalysis <xref target="BH2013" />
	and progress in the development of quantum computers <xref
	target="NAS2019" /> pose a threat to widely deployed digital
	signature algorithms.  As a result, there is a need to prepare
	for a day that cryptosystems such as RSA and DSA that depend
	on discrete logarithm and factoring cannot be depended upon.</t>

	<t>If large-scale quantum computers are ever built, these
	computers will be able to break many of the public-key
	cryptosystems currently in use.  A post-quantum cryptosystem
	<xref target="PQC" /> is a system that is secure against
	quantum computers that have more than a trivial number of
	quantum bits (qubits).  It is open to conjecture when it will
	be feasible to build such computers; however, RSA, DSA, ECDSA,
	and EdDSA are all vulnerable if large-scale quantum computers
	come to pass.</t>

	<t>WalnutDSA does not depend on the difficulty of discrete
	logarithm or factoring.  As a result this algorithm is
	considered to be resistant to post-quantum attacks.</t>
	
	<t>Today, RSA and ECDSA are often used to digitally sign
	software updates.  Unfortunately, implementations of RSA and
	ECDSA can be relatively large, and verification can take a
	significant amount of time on some very small processors.
	Therefore, we desire a digital signature scheme that verifies
	faster with less code.  Moreover, in preparation for a day
	when RSA, DSA, and ECDSA cannot be depended upon, a digital
	signature algorithm is needed that will remain secure even if
	there are significant cryptoanalytic advances or a large-scale
	quantum computer is invented.  WalnutDSA, specified in <xref
	target="WALNUTSPEC" />, is a quantum-resistant algorithm
	that addresses these requirements.</t>
      </section>

      <section title="Trademark Notice">
	<t>WalnutDSA(TM) and Walnut Digital Signature Algorithm(TM) are
	trademarks of Veridify Security Inc..</t>
      </section>
    </section>

    <section title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      BCP 14 <xref target="RFC2119" />
      <xref target="RFC8174" /> when, and only when,
      they appear in all capitals, as shown here.</t>
    </section>

    <section title="WalnutDSA Algorithm Overview" anchor="alg_overview">
      <t>This specification makes use of WalnutDSA signatures as
      described in <xref target="WALNUTDSA" /> and more concretely
      specified in <xref target="WALNUTSPEC" />.  WalnutDSA is a
      Group-Theoretic cryptographic signature scheme that leverages
      infinite group theory as the basis of its security and maps that
      to a one-way evaluation of a series of matrices over small
      finite fields with permuted multiplicants based on the group
      input.  WalnutDSA leverages the SHA2-256 and SHA2-512 one-way
      hash algorithms <xref target="SHA2" /> in a hash-then-sign
      process.</t>

      <t>WalnutDSA is based on a one-way function, E-Multiplication,
      which is an action on the infinite group.  A single
      E-Multiplication step takes as input a matrix and permutation, a
      generator in the group, and a set of T-values (entries in the
      finite field) and outputs a new matrix and permutation.  To
      process a long string of generators (like a WalnutDSA
      signature), E-Multiplication is iterated over each generator.
      Due to its structure, E-Multiplication is extremely easy to
      implement.</t>
      
      <t>In addition to being quantum-resistant, the two main benefits
      of using WalnutDSA are that the verification implementation is
      very small and WalnutDSA signature verification is extremely
      fast, even on very small processors (including 16- and even
      8-bit MCUs).  This lends it well to use in constrained and/or
      time-sensitive environments.</t>

      <t>WalnutDSA has several parameters required to process a
      signature.  The main parameters are N and q.  The parameter N
      defines the size of the group by defining the number of strands in use,
      and implies working in an NxN
      matrix.  The parameter q defines the number of elements in the finite field.
      Signature verification also requires a set of
      T-values, which is an ordered list of N entries in the finite
      field F_q.</t>

      <t>A WalnutDSA signature is just a string of generators in the
      infinite group, packed into a byte string.</t>
    </section>

    <section title="WalnutDSA Algorithm Identifiers" anchor="alg_ids">
      <t>The CBOR Object Signing and Encryption (COSE) <xref
      target="RFC8152" /> supports two signature algorithm schemes.
      This specification makes use of the signature with appendix
      scheme for WalnutDSA signatures.</t>

      <t>The signature value is a large byte string.  The byte string is
      designed for easy parsing, and it includes a length (number of
      generators) and type codes that indirectly provide all of the
      information that is needed to parse the byte string during
      signature validation.</t>

      <t>When using a COSE key for this algorithm, the following checks are
      made:</t>

      <t><list style="symbols">
	<t>The 'kty' field MUST be present, and it MUST be 'WalnutDSA'.</t>
	<t>If the 'alg' field is present, and it MUST be 'WalnutDSA'.</t>
	<t>If the 'key_ops' field is present, it MUST include 'sign' when
	creating a WalnutDSA signature.</t>
	<t>If the 'key_ops' field is present, it MUST include 'verify'
	when verifying a WalnutDSA signature.</t>
	<t>If the 'kid' field is present, it MAY be used to identify the
	WalnutDSA Key.</t>
      </list></t>
    </section>

    <section title="Security Considerations" anchor="sec_consider">
      <section title="Implementation Security Considerations">
	<t>Implementations MUST protect the private keys.  Use of a hardware
	security module (HSM) is one way to protect the private keys.
	Compromise of the private keys may result in the ability to forge
	signatures.  As a result, when a private key
	is stored on non-volatile media or stored in a virtual machine
	environment, care must be taken to preserve confidentiality and
	integrity.</t>

	<t>The generation of private keys relies on random numbers.  The use of
	inadequate pseudo-random number generators (PRNGs) to generate these
	values can result in little or no security.  An attacker may find it
	much easier to reproduce the PRNG environment that produced the keys,
	searching the resulting small set of possibilities, rather than brute
	force searching the whole key space.  The generation of quality
	random numbers is difficult, and <xref target="RFC4086" />
	offers important guidance in this area.</t>

	<t>The generation of WalnutDSA signatures also depends on random
	numbers.  While the consequences of an inadequate pseudo-random
	number generator (PRNG) to generate these values is much less severe
	than the generation of private keys, the guidance in <xref target="RFC4086" />
	remains important.</t>
      </section>

      <section title="Method Security Considerations">
	<t>The Walnut Digital Signature Algorithm has undergone
	significant cryptanalysis since it was first introduced, and
	several weaknesses were found in early versions of the method,
	resulting in the description of several attacks with exponential
	computational complexity.
	A full writeup of all the analysis can be found in
	<xref target="WalnutDSAAnalysis" />.  In summary,
	the original suggested parameters (N=8, q=32) were too small, leading to
	many of these exponential-growth attacks being practical.  However, current
	parameters render these attacks impractical.  The following
	paragraphs summarize the analysis and how the current
	parameters defeat all the previous attacks.</t>

	<t>First, the team of Hart et al found a universal forgery
	attack based on a group factoring problem that runs in
	O(q^((N-1)/2)) with a memory complexity of log_2(q) N^2
	q^((N-1)/2).  With parameters N=10 and q=M31 (the Mersenne prime 2^31 - 1), the
	runtime is 2^139 and memory complexity is 2^151.  W. Beullens
	found a modification of this attack but its runtime is even
	longer.</t>

	<t>Next, Beullens and Blackburn found several issues with the
	original method and parameters.  First they used a Pollard-Rho
	attack and discovered the original public key space was too
	small.  Specifically they require that q^(N(N-1)-1) >
	2^(2*Security Level).  One can clearly see that N=10, q=M31
	provides 128-bit security and N=10, q=M61 provides 256-bit
	security.</t>

	<t>Beullens and Blackburn also found two issues with the
	original message encoder of WalnutDSA.  First, the original
	encoder was non-injective, which reduced the available
	signature space.  This was repaired in an update.  Second,
	they pointed out that the dimension of the vector space
	generated by the encoder was too small.  Specifically, they
	require that q^dimension > 2^(2*Security Level).  With N=10,
	the current encoder produces a dimension of 66 which clearly
	provides sufficient security with q=M31 or q=M61.</t>

	<t>The final issue discovered by Beullens and Blackburn was a
	process to theoretically "reverse" E-Multiplication. First, their
	process requires knowing the initial matrix and permutation
	(which is known for WalnutDSA).  But more importantly, their
	process runs at O(q^((N-1)/2)) which, for N=10, q=M31 is
	greater than 2^128.</t>

	<t>A team at Steven's Institute leveraged a length-shortening
	attack that enabled them to remove the cloaking elements and
	then solve a conjugacy search problem to derive the private
	keys.  Their attack requires both knowledge of the permutation
	being cloaked and also that the cloaking elements themselves
	are conjugates.  By adding additional concealed cloaking
	elements the attack requires an N! search for each cloaking
	element.  By inserting k concealed cloaking elements, this
	requires the attacker to perform (N!)^k work.  This allows
	k to be set to meet the desired security level.</t>

	<t>Finally, Merz and Petit discovered that using a Garside
	Normal Form of a WalnutDSA signature enabled them to find
	commonalities with the Garside Normal Form of the encoded
	message.  Using those commonalities they were able to splice
	into a signature and create forgeries.  Increasing the number
	of cloaking elements, specifically within the encoded message,
	sufficiently obscures the commonalities and blocks this
	attack.</t>

	<t>In summary, most of these attacks are exponential in run
	time and can be shown that current parameters put the runtime
	beyond the desired security level.  The final two attacks are
	also sufficiently blocked to the desired security level.</t>
      </section>

    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="IANA" title="IANA Considerations">
      <t>IANA is requested to add entries for WalnutDSA signatures in the
      "COSE Algorithms" registry and WalnutDSA public keys in the "COSE
      Key Types" and "COSE Key Type Parameters" registries.</t>

      <section title="COSE Algorithms Registry Entry">
	<t>The new entry in the "COSE Algorithms" registry has the following
	columns:</t>
	<t><list>
	  <t>Name:  WalnutDSA</t>
	  <t>Value:  TBD1 (Value between -65536 to -257 or 256-65535  to be assigned by IANA)</t>
	  <t>Description:  WalnutDSA signature</t>
	  <t>Reference:  This document (Number to be assigned by RFC Editor)</t>
	  <t>Recommended:  No</t>
	</list></t>
      </section>

      <section title="COSE Key Types Registry Entry">
	<t>The new entry in the "COSE Key Types" registry has the following
	columns:</t>
	<t><list>
	  <t>Name:  WalnutDSA</t>
	  <t>Value:  TBD2 (Value to be assigned by IANA)</t>
	  <t>Description:  WalnutDSA public key</t>
	  <t>Reference:  This document (Number to be assigned by RFC Editor)</t>
	</list></t>
      </section>

      <section title="COSE Key Type Parameter Registry Entries">
	<t>The following sections detail the additions to the "COSE Key Type Parameters" registry.</t>

	<section title="WalnutDSA Parameter: N">
	  <t>The new entry N in the "COSE Key Type Parameters" registry
	  has the following columns:</t>
	  <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: N</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: uint</t>
	    <t>Description: Group and Matrix (NxN) size</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>

	<section title="WalnutDSA Parameter: q">
	  <t>The new entry q in the "COSE Key Type Parameters" registry
	  has the following columns:</t>
      	  <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: q</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: uint</t>
	    <t>Description: Finite field F_q</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>

	<section title="WalnutDSA Parameter: t-values">
	  <t>The new entry t-values in the "COSE Key Type Parameters" registry
	  has the following columns:</t>
      	  <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: t-values</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: array (of uint)</t>
	    <t>Description: List of T-values, enties in F_q</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>

	<section title="WalnutDSA Parameter: matrix 1">
	  <t>The new entry matrix 1 in the "COSE Key Type Parameters" registry
	  has the following columns:</t>
      	  <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: matrix 1</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: array (of array of uint)</t>
	    <t>Description: NxN Matrix of enties in F_q in column-major form</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>

	<section title="WalnutDSA Parameter: permutation 1">
	  <t>The new entry permutation 1 in the "COSE Key Type Parameters" registry
	  has the following columns:</t>	  
          <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: permutation 1</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: array (of uint)</t>
	    <t>Description: Permutation associated with matrix 1</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>

	<section title="WalnutDSA Parameter: matrix 2">
	  <t>The new entry matrix 2 in the "COSE Key Type Parameters" registry
	  has the following columns:</t>
          <t><list>
	    <t>Key Type: TBD2 (Value assigned by IANA above)</t>
	    <t>Name: matrix 2</t>
	    <t>Label: TBD (Value to be assigned by IANA)</t>
	    <t>CBOR Type: array (of array of uint)</t>
	    <t>Description: NxN Matrix of enties in F_q in column-major form</t>
	    <t>Reference: This document (Number to be assigned by RFC Editor)</t>
	  </list></t>
	</section>
      </section>

    </section>

  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      &RFC2119;

      &RFC8174;

      &RFC8152;

      <reference anchor="SHA2">
	<front>
          <title>FIPS Publication 180-3: Secure Hash Standard</title>
          <author initials="" surname="" fullname="">
            <organization>National Institute of Standards and Technology (NIST)</organization>
          </author>
          <date month="October" year="2008" />
        </front>
      </reference>

      <reference anchor="WALNUTDSA" target="https://doi.org/10.1080/23799927.2020.1831613">
	<front>
          <title>WalnutDSA(TM): A group-theoretic digital signature algorithm</title>
          <author initials="I.A." surname="Anshel" fullname="Iris Anshel">
            <organization />
          </author>
          <author initials="D.A." surname="Atkins" fullname="Derek Atkins">
            <organization />
          </author>
          <author initials="D.G." surname="Goldfeld" fullname="Dorian Goldfeld">
            <organization />
          </author>
          <author initials="P.G." surname="Gunnells" fullname="Paul E Gunnells">
            <organization />
          </author>
          <date month="November" year="2020" />
        </front>
      </reference> 
   </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      <!-- A reference written by by an organization not a person. -->
      <reference anchor="WALNUTSPEC" target="https://csrc.nist.gov/projects/post-quantum-cryptography/round-1-submissions">
	<front>
          <title>The Walnut Digital Signature Algorithm Specification</title>
          <author initials="I.A." surname="Anshel" fullname="Iris Anshel">
            <organization />
          </author>
          <author initials="D.A." surname="Atkins" fullname="Derek Atkins">
            <organization />
          </author>
          <author initials="D.G." surname="Goldfeld" fullname="Dorian Goldfeld">
            <organization />
          </author>
          <author initials="P.G." surname="Gunnells" fullname="Paul E Gunnells">
            <organization />
          </author>
          <date month="November" year="2018" />
        </front>
      </reference>

      <reference anchor="GTC" target="https://www.crcpress.com/Group-Theoretic-Cryptography/Vasco-Steinwandt/p/book/9781584888369">
	<front>
          <title>Group Theoretic Cryptography</title>
          <author initials="M.I.G.V." surname="Vasco" fullname="Maria Isabel Gonzalez Vasco">
            <organization />
          </author>
          <author initials="R.S." surname="Steinwandt" fullname="Rainer Steinwandt">
            <organization />
          </author>
          <date month="April" year="2015" />
        </front>
      </reference>

      <reference anchor="WalnutDSAAnalysis" target="https://eprint.iacr.org/2019/472">
	<front>
          <title>Defeating the Hart et al, Beullens-Blackburn, Kotov-Menshov-Ushakov, and Merz-Petit Attacks on WalnutDSA(TM)</title>
          <author initials="I.A." surname="Anshel" fullname="Iris Anshel">
            <organization />
          </author>
          <author initials="D.A." surname="Atkins" fullname="Derek Atkins">
            <organization />
          </author>
          <author initials="D.G." surname="Goldfeld" fullname="Dorian Goldfeld">
            <organization />
          </author>
          <author initials="P.G." surname="Gunnells" fullname="Paul E Gunnells">
            <organization />
          </author>
          <date month="May" year="2019" />
        </front>
      </reference>

      &RFC4086;

      <reference anchor="BH2013" target="https://media.blackhat.com/us-13/us-13-Stamos-The-Factoring-Dead.pdf">
	<front>
          <title>The Factoring Dead: Preparing for the Cryptopocalypse</title>
          <author initials="T.P." surname="Ptacek" fullname="">
            <organization />
          </author>
          <author initials="J.R." surname="Ritter" fullname="">
            <organization />
          </author>
          <author initials="J.S." surname="Samuel" fullname="">
            <organization />
          </author>
          <author initials="A.S." surname="Stamos" fullname="">
            <organization />
          </author>
          <date month="August" year="2013" />
        </front>
      </reference>

      <reference anchor="NAS2019" target="http://dx.doi.org/10.17226/25196">
	<front>
          <title>Quantum Computing: Progress and Prospects</title>
          <author >
            <organization>National Academies of Sciences, Engineering, and Medicine</organization>
          </author>
          <date year="2019" />
        </front>
      </reference>

      <reference anchor="PQC" target="http://www.pqcrypto.org/www.springer.com/cda/content/document/cda_downloaddocument/9783540887010-c1.pdf">
	<front>
	  <title>Introduction to post-quantum cryptography</title>
	    <author initials="D.B." surname="Bernstein">
	      <organization />
	    </author>
	    <date month="" year="2009" />
	  </front>
      </reference>

      <!--
      <reference anchor="S1997" target="http://dx.doi.org/10.1137/S0097539795293172">
	<front>
          <title>Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer</title>
          <author initials="P.S." surname="Shor" fullname="Peter Shor">
            <organization />
          </author>
          <date year="1997" />
        </front>
	<seriesInfo name="SIAM Journal on Computing 26(5)," value="1484-26"/>
      </reference>
      -->

    </references>

    <section anchor="Acknowledgments" title="Acknowledgments">
      <t>A big thank you to Russ Housley for his input on the concepts and text of this document.</t>
    </section>

    <!--
	<section anchor="app-additional" title="Additional Stuff">
	<t>This becomes an Appendix.</t>
	</section>
    -->

    <!-- Change Log

v00 2019-03-20  DA    Initial version

v01 2019-11-04  DA    Convert to Informational
                      Edits to be more in line with the Hash-Sig draft

v02 2019-12-20  DA    Incorporated suggestions from reviews (ISE, etc)

v03 2020-06-15  DA    Refresh document

v04 2020-07-08  DA    Suggested changes from Adrian

v05 2020-11-05  DA    More suggestions from Adrian and fixing references

v06 2021-01-26  DA    Changes from IESG
    -->
  </back>
</rfc>
