<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->

<!-- <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> -->
<!ENTITY RFC3279 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3279.xml">
<!ENTITY RFC3280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3280.xml">
<!ENTITY RFC4055 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4055.xml">
<!ENTITY RFC4086 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4086.xml">
<!ENTITY RFC5280 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5280.xml">
<!ENTITY RFC5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY RFC8017 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8017.xml">
<!ENTITY I-D.draft-josefsson-pkix-eddsa SYSTEM "http://xml2rfc.tools.ietf.org/public/rfc/bibxml-ids/reference.I-D.draft-josefsson-pkix-eddsa-04.xml">
]> 
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-lamps-pkix-shake-02" ipr="trust200902">
  <!-- 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 as Hash Functions</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->
    <author fullname="Panos Kampanakis" initials="P.K."
            surname="Kampanakis">
      <organization>Cisco Systems</organization>
      <address>
        <email>pkampana@cisco.com</email>
      </address>
    </author>
    <author fullname="Quynh Dang" initials="Q.D."
            surname="Dang">
      <organization>NIST</organization>
      <address>
         <postal>
          <street>100 Bureau Drive, Stop 8930</street>
          <city>Gaithersburg</city>
          <region>MD</region>
          <code>20899-8930</code>
          <country>USA</country>
        </postal>
        <!-- <phone>+44 7889 488 335</phone> -->
        <email>quynh.dang@nist.gov</email>
        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <!-- <author fullname="Sean Turner" initials="S.T."
            surname="Turner">
      <organization>sn3rd</organization>
      <address>
        <postal>
          <street></street>
          <city>Soham</city>
          <region></region>
          <code></code>
          <country>UK</country>
        </postal>
        <phone>+44 7889 488 335</phone>
        <email>sean@sn3rd.com</email> 
      </address>
    </author> -->

    <date year="2018" />

    <!-- 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 (Certificate Revocation Lists). This 
	  document describes the conventions for using the SHAKE family of 
	  hash functions in the Internet X.509 as one-way hash functions 
	  with the RSA Probabilistic Signature Scheme and ECDSA signature 
	  algorithms. The conventions for the associated subject public 
	  keys are also described.</t>
    </abstract>
  </front>

  <middle>
  
    <section title="Change Log">
	  <t>[ EDNOTE: Remove this section before publication. ]</t>
      <t><list style="symbols"> 
	    <t>draft-ietf-lamps-pkix-shake-02:
		  <list> 
		  <t>Significant reorganization of the sections to simplify the introduction, the new OIDs and their use in PKIX.</t>
		  <t>Added new OIDs for RSASSA-PSS that hardcode hash, salt and MFG, according the WG consensus.</t>
		  <t>Updated Public Key section to use the new RSASSA-PSS OIDs and clarify the algorithm identifier usage.</t>
		  <t>Removed the no longer used SHAKE OIDs from section 3.1.</t>
		  <t>Consolidated subsection for message digest algorithms.</t>
		  <t>Text fixes.</t>
	    </list></t>
	    <t>draft-ietf-lamps-pkix-shake-01:
		  <list> 
		  <t>Changed titles and section names.</t>
	      <t>Removed DSA after WG discussions.</t>
		  <t>Updated shake OID names and parameters, added MGF1 section.</t>
		  <t>Updated RSASSA-PSS section.</t>
		  <t>Added Public key algorithm OIDs.</t>
		  <t>Populated Introduction and IANA sections.</t>
	    </list></t>
	    <t>draft-ietf-lamps-pkix-shake-00:
		  <list> 
	      <t>Initial version</t>
	    </list></t>
	  </list></t>
    </section>

    <section title="Introduction">
      <t>This document describes several cryptographic algorithm identifiers 
	  for several cryptographic algorithms which use variable length output 
	  SHAKE functions introduced in <xref target="SHA3"/> which can be used 
	  with the Internet X.509 Certificate and CRL profile <xref target="RFC5280"/>. </t>
	  
      <t>The SHA-3 family of one-way hash functions is specified in <xref target="SHA3"/>. 
	  In the SHA-3 family, two extendable-output functions, called SHAKE128 and SHAKE256 are 
	  defined. Four hash functions, 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. 
	  The output lengths, in bits, of the SHAKE hash functions are defined by the d parameter. 
	  The corresponding collision and preimage resistance security levels for SHAKE128 and SHAKE256 
	  are respectively min(d/2,128) and min(d,128) and min(d/2,256) and min(d,256) bits. </t>
	  
	  <t>SHAKEs can be used as the message digest function (to hash the message to be signed) and as the hash function in the mask generating functions in RSASSA-PSS 
	  and ECDSA. In this document, we define four new OIDs for RSASSA-PSS and ECDSA when SHAKE128 and SHAKE256 
	  are used as hash functions. The same algorithm identifiers are used for 
	  identifying a public key, and identifying a signature. </t>
    </section>

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>

    <section title="Identifiers" anchor="oids">
	  <!-- Commention out the below OIDs as they are no longer pertinent for the below public keys and sigs -->
	  <!-- The Object Identifiers (OIDs) for these two hash functions are defined in 
	  <xref target="shake-nist-oids"/> and are included here for convenience: </t>
      
	  <t><figure><artwork><![CDATA[
  id-shake128-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
		country(16) us(840) organization(1) gov(101) csor(3)
		nistalgorithm(4) hashalgs(2) 17 } 
				
  ShakeOutputLen ::= INTEGER - - Output length in octets
]]></artwork></figure></t>
	  <t>When using the id-shake128-len algorithm identifier, the parameters 
	  MUST be present, and they MUST employ the ShakeOutputLen -->
	  <!-- "MUST employ syntax borrowed from RFC4055 -->
	  <!-- syntax that contains an encoded positive integer value at least 32  
	  in this specification.</t>
	  <t><figure><artwork><![CDATA[
  id-shake256-len OBJECT IDENTIFIER ::= { joint-iso-itu-t(2)
		country(16) us(840) organization(1) gov(101) csor(3)
		nistalgorithm(4) hashalgs(2) 18 }   
			
  ShakeOutputLen ::= INTEGER - - Output length in octets
]]></artwork></figure></t>
	  <t>When using the id-shake256-len algorithm identifier, the parameters 
	  MUST be present, and they MUST employ the ShakeOutputLen -->
	  <!-- "MUST employ syntax borrowed from RFC4055 -->
	  <!-- syntax that contains an encoded positive integer value at least 64 
	  in this specification.</t>	-->

	  <t>The new identifiers for RSASSA-PSS signatures using SHAKEs are below.</t>
	  
	  <t><figure><artwork><![CDATA[
  id-RSASSA-PSS-SHAKE128  OBJECT IDENTIFIER  ::=  { TBD }
]]></artwork></figure></t>

	        <t><figure><artwork><![CDATA[
  id-RSASSA-PSS-SHAKE256  OBJECT IDENTIFIER  ::=  { TBD }
   
  [ EDNOTE: "TBD" will be specified by NIST later. ]
]]></artwork></figure></t>
		           
 	  <t>The new algorithm identifiers of ECDSA signatures using SHAKEs are below.</t> 
      <t><list>
	    <t><figure><artwork><![CDATA[
  id-ecdsa-with-shake128 OBJECT IDENTIFIER  ::=  { joint-iso-ccitt(2) 
			country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 
			id-ecdsa-with-shake(3) TBD }
]]></artwork></figure></t>
		<t><figure><artwork><![CDATA[
  id-ecdsa-with-shake256 OBJECT IDENTIFIER  ::=  { joint-iso-ccitt(2) 
			country(16) us(840) organization(1) gov(101) csor(3) algorithms(4) 
			id-ecdsa-with-shake(3) TBD }
			
  [ EDNOTE: "TBD" will be specified by NIST later. ]
]]></artwork></figure></t>
	  </list></t> 
	  
	  <!-- <xref target="RFC8017"/>, but we include it here as well for convenience:</t>
	  <t><figure><artwork><![CDATA[
   id-mgf1  OBJECT IDENTIFIER  ::=  { pkcs-1 8 }
]]></artwork></figure>--> 
	  <!-- <t>The parameters field associated with id-mgf1 MUST have a hashAlgorithm value that identifies 
	  the hash used with MGF1. To use SHAKE as this hash, this parameter MUST be 
	  id-shake128-len or id-shake256-len as specified in <xref target="xofs" /> above. </t>--> 
    
	  <t>The parameters for these four identifiers above MUST be absent. That is, 
	  the identifier SHALL be a SEQUENCE of one component, the OID.</t>
	
	</section> 
	
	<section title="Use in PKIX">

	  <section title="Signatures" anchor="sigs">
	  
	    <t>Signatures can be placed in a number of different ASN.1 structures.
        The top level structure for an X.509 certificate, to illustrate 
        how signatures are frequently encoded with an algorithm identifier 
		and a location for the signature, is </t>
        <t><figure><artwork><![CDATA[
   Certificate  ::=  SEQUENCE  {
      tbsCertificate       TBSCertificate,
      signatureAlgorithm   AlgorithmIdentifier,
      signatureValue       BIT STRING  }
]]></artwork></figure></t>
	  
	    <t>The identifiers defined in <xref target="oids"/> can be used 
		as the AlgorithmIdentifier in the signatureAlgorithm field in the sequence 
		Certificate and the signature field in the sequence tbsCertificate in X.509 
		<xref target="RFC3280"/>.</t>
		
		<t>Conforming CA implementations MUST specify the algorithms  
		explicitly by using the OIDs specified in <xref target="oids"/> when 
		encoding RSASSA-PSS and ECDSA with SHAKE signatures, and public keys 
		in certificates and CRLs. Encoding rules for RSASSA-PSS and ECDSA 
		signature values are specified in <xref target="RFC4055"/> and 
		<xref target="RFC5480"/> respectively.</t>
		
		<t>Conforming client implementations that process RSASSA-PSS and ECDSA 
		with SHAKE signatures when processing certificates and CRLs 
		MUST recognize the corresponding OIDs.</t>
		
		<section title="RSASSA-PSS Signatures" anchor="rsa-sigs">		  
		  <t>The RSASSA-PSS algorithm is defined in <xref target="RFC8017"/>. 
		  When id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in <xref target="oids"/> 
		  is used, the encoding MUST omit the parameters field. That is, 
		  the AlgorithmIdentifier SHALL be a SEQUENCE of one component,  
		  id-RSASSA-PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. </t>
		  
		  <t>The hash algorithm to hash a message being signed and the hash algorithm in the 
		  maskGenAlgorithm used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. 
		  The output-length of the hash algorithm which hashes the message SHALL be 
		  32 or 64 bytes respectively. </t> 
			
	      <t>The maskGenAlgorithm is the MGF1 specified in Section B.2.1 of <xref target="RFC8017"/>. 
		  The output length for SHAKE128 or SHAKE256 being used as the hash function in MGF1 
		  is (n - 264)/8 or (n - 520)/8 bytes respectively, where n is the RSA modulus 
		  in bits. For example, when RSA modulus n is 2048, the output length of SHAKE128 or 
		  SHAKE256 in the MGF1 will be 223 or 191 when id-RSASSA-PSS-SHAKE128 or 
		  id-RSASSA-PSS-SHAKE256 is used respectively. </t>
		      
		  <t>The RSASSA-PSS saltLength MUST be 32 
		  or 64 bytes respectively. Finally, the trailerField MUST be 1, which represents 
		  the trailer field with hexadecimal value 0xBC <xref target="RFC8017"/>.</t>
		<!-- <t><figure><artwork><![CDATA[
   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 k }

   RSASSA-PSS-params  ::=  SEQUENCE  {
         hashAlgorithm      HashAlgorithm, 
         maskGenAlgorithm   MaskGenAlgorithm, 
         saltLength         INTEGER, 
         trailerField       INTEGER }
]]></artwork></figure></t> -->

        <!-- <section title="EdDSA with SHAKE">
          <t>[ EDNOTE: For the group to decide: pre-hash version or non-prehash version EdDSAs. PureEdDSA, the pre-hashed version of EdDSA, as currently also proposed in draft-ietf-curdle-cms-eddsa-signatures mandates the hash function as SHA512 for Ed25519 and SHAKE256(x,64) for Ed448. The HashEdDSA version of EdDSA does not define the hash. It is up to the WG to go the Pre-hash route which would require an OID that contained the hash. ] </t>
		  <t>
		     <list>
			   <t><figure><artwork><![CDATA[
id-eddsa-with-shake128 OBJECT IDENTIFIER ::= { }
]]></artwork></figure></t>
			   <t><figure><artwork><![CDATA[
id-eddsa-with-shake256 OBJECT IDENTIFIER ::= {  }
]]></artwork></figure></t>
			   </list></t>
        </section> -->	  
		</section>
		
		<section title="ECDSA Signatures" anchor="ecdsa-sigs">
	      <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 
	      <xref target="X9.62"/>. When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256
		  (specified in <xref target="oids"/>) algorithm identifier appears, the respective SHAKE 
		  function (SHAKE128 or SHAKE256) is used as the hash. 
		  The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier 
		  SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-SHAKE128 or 
		  id-ecdsa-with-SHAKE256.</t>
	      
          <t>For simplicity and compliance with the ECDSA standard specification, 
	      the output size of the hash function must be explicitly determined. The 
	      output size, d, for SHAKE128 or SHAKE256 used in ECDSA MUST be 256 or 512  
		  bits respectively. </t>
	  	  	
		  <t>Conforming CA implementations that generate ECDSA with SHAKE signatures 
		  in certificates or CRLs MUST generate such signatures in accordance 
		  with all the requirements specified in Sections 7.2 and 7.3 of 
		  <xref target="X9.62"/> or with all the requirements specified in Section 
		  4.1.3 of <xref target="SEC1"/>. They MAY also generate such signatures 
		  in accordance with all the recommendations in <xref target="X9.62"/> or 
		  <xref target="SEC1"/> if they have a stated policy that requires 
		  conformance to these standards. These standards may have not specified 
		  SHAKE128 and SHAKE256 as hash algorithm options. However, SHAKE128 and 
		  SHAKE256 with output length being 32 and 64 octets respectively are 
		  subtitutions for 256 and 512-bit output hash algorithms such as SHA256 
		  and SHA512 used in the standards.</t>
          </section>
	    </section>

	  <section title="Public Keys">
	    <t>Certificates conforming to <xref target="RFC5280"/> can convey a 
		public key for any public key algorithm. The certificate indicates 
		the algorithm through an algorithm identifier. This algorithm 
		identifier is an OID and optionally associated parameters.</t>
   
        <t>In the X.509 certificate, the subjectPublicKeyInfo field has the
        SubjectPublicKeyInfo type, which has the following ASN.1 syntax: </t>
        
		<t><figure><artwork><![CDATA[
  SubjectPublicKeyInfo  ::=  SEQUENCE  {
       algorithm         AlgorithmIdentifier,
       subjectPublicKey  BIT STRING
  }
]]></artwork></figure></t>
   
        <t>The fields in SubjectPublicKeyInfo have the following meanings:
        <list style="symbols"> 
          <t>algorithm is the algorithm identifier and parameters for the
           public key.</t>
          <t>subjectPublicKey contains the byte stream of the public key. The
          algorithms defined in this document always encode the public key
          as an exact multiple of 8-bits.</t>
        </list></t>
   	  
		<t>The conventions for RSASSA-PSS and ECDSA <!-- and EdDSA --> public keys 
		algorithm identifiers are as specified in <xref target="RFC3279"/>, 
		<xref target="RFC4055"/> and <xref target="RFC5480"/> 
		<!-- and <xref target="I-D.josefsson-pkix-eddsa"/>-->, 
		but we include them below for convenience.</t>
	    
		<section title="RSASSA-PSS Public Keys"> 
	
		  <t><xref target="RFC3279"/> defines the following OID for RSA AlgorithmIdentifier 
		  in the SubjectPublicKeyInfo with NULL parameters.</t>
		  <t><figure><artwork><![CDATA[
  rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}
]]></artwork></figure></t>
	    		  
		  <t>Additionally, when the RSA private key owner wishes to limit the use of 
		  the public key exclusively to RSASSA-PSS, the AlgorithmIdentifiers for 
		  RSASSA-PSS defined in <xref target="oids"/> can be used as the algorithm 
		  field in the SubjectPublicKeyInfo sequence <xref target="RFC3280"/>. The 
		  identifier parameters, as explained in section <xref target="oids"/>, MUST be 
		  absent. </t>
		  
		  <t>Regardless of what public key algorithm identifier is used, the RSA public 
		  key, which is composed of a modulus and a public exponent, MUST be encoded 
		  using the RSAPublicKey type <xref target="RFC4055"/>. The output of this 
		  encoding is carried in the certificate subjectPublicKey. </t>
          <t><figure><artwork><![CDATA[
  RSAPublicKey ::= SEQUENCE {
        modulus INTEGER, -- n
        publicExponent INTEGER  -- e
  }
]]></artwork></figure></t> 
		</section>
		
        <section title="ECDSA Public Keys">
		  <t>For ECDSA, when id-ecdsa-with-shake128 or id-ecdsa-with-shake256 
		  is used as the AlgorithmIdentifier in the algorithm field of SubjectPublicKeyInfo, 
		  the parameters, as explained in section <xref target="oids"/>, MUST be absent. </t>
		  
		  <t>Additionally, the mandatory EC SubjectPublicKey is defined in Section 2.1.1 
		  and its syntax is in Section 2.2 of <xref target="RFC5480"/>. We also include them 
		  here for convenience: </t>
		  
		  <t><figure><artwork><![CDATA[
  id-ecPublicKey OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
]]></artwork></figure></t>

          <t>The id-ecPublicKey parameters MUST be present and are defined as </t>	   
	      <t><figure><artwork><![CDATA[
  ECParameters ::= CHOICE {
      namedCurve         OBJECT IDENTIFIER
      -- implicitCurve   NULL
      -- specifiedCurve  SpecifiedECDomain 
   }
]]></artwork></figure></t>
          <t>The ECParameters associated with the ECDSA public key in the signer's 
	      certificate SHALL apply to the verification of the signature.</t>
        </section>
	  </section>
	  
	</section>

    <section anchor="IANA" title="IANA Considerations">
      <!-- <t>IANA is kindly requested to register two OIDs in the SMI Security for
      PKIX Module Identifier registry for the ASN.1 modules found in
      <xref target="asn"/>.  The description is as follows:
      <list style="symbols">
	    <t></t>
      </list>
      where the four digits at the end represent the ASN.1's publication
      date.</t> -->
	  <t><!-- This document uses several registries that were originally created in <xref target="shake-nist-oids"/>. -->
	  This document uses several new registries [ EDNOTE: Update here. ]</t>
    </section>

    <section anchor="Security" title="Security Considerations">  
      <!-- <t>SHAKE128 and SHAKE256 are one-way extensible-output functions. Their output 
	  length depends on a required length of the consumming application. </t> -->
      
      <t>The SHAKEs are deterministic functions. Like any other deterministic functions, 
	  executing each  function with the same input multiple times will produce the 
	  same output. Therefore, users should not expect unrelated outputs (with the 
	  same or different output lengths) from excuting a SHAKE function with the 
	  same input multiple times. </t>
	  
	  <t>Implementations must protect the signer's private key. Compromise of
      the signer's private key permits masquerade.</t>

	  <t>Implementations must randomly generate one-time values, such as the k value when generating a ECDSA
      signature. In addition, the generation of public/private key pairs
      relies on random numbers. The use of inadequate pseudo-random
      number generators (PRNGs) to generate such cryptographic values can
      result in little or no security. The generation of quality random
      numbers is difficult. <xref target="RFC4086"/> offers important guidance 
	  in this area, and <xref target="SP800-90A"/> series provide acceptable 
      PRNGs.</t>
      
	  <t>Implementers should be aware that cryptographic algorithms may 
	  become weaker with time. As new cryptanalysis techniques are developed 
	  and computing power increases, the work factor or time required to break a 
	  particular cryptographic algorithm may decrease. Therefore, cryptographic
      algorithm implementations should be modular allowing new algorithms
      to be readily inserted. That is, implementers should be prepared to
      regularly update the set of algorithms in their implementations.</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>We would like to thank Sean Turner for his valuable contributions to this document.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <!-- &RFC2119; -->
	  &RFC3280;
	  &RFC4055;
      &RFC5280;
	  &RFC5480;
	  &RFC8017;
	  <!-- <?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</organization>
          </author>
          <date month="August" year="2015" />
        </front>
      </reference>
	</references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->
      <!--&RFC2629; -->
	  &RFC3279;
	  &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-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>
    </references>

    <section anchor="asn" title="ASN.1 module">
	  <t>[ EDNOTE: More here. ] </t>
    </section>

  </back>
</rfc>
