<?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 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-01" 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 SHAKE Algorithms and Identifiers for RSA and ECDSA</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 month="February" 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>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 and ECDSA signature algorithms; the 
	  conventions for the associated subject public keys are also 
	  described. Digital signatures are used to sign messages, 
	  certificates and CRLs (Certificate Revocation Lists).</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-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 algorithms which may be used 
	  with the Internet X.509 Certificate and CRL profile <xref target="RFC5280"/>. 
	  It describes the OIDs for variable length SHAKE algorithms introduced in <xref target="SHA3"/> 
	  and how they can be used in X.509 certificates. [ EDNOTE: Update here. ] </t>
    </section>

    <!-- This PI places the pagebreak correctly (before the section title) in the text output. -->

    <?rfc needLines="8" ?>

    <section title="Message Digest Algorithms">
	  <t>This section describes two one-way hash functions and digital signature 
   algorithms using these functions, which may be used to sign certificates and 
   CRLs, and identifies OIDs (Object Identifiers) for public keys contained in 
   certificates.</t>
      <section title="One-way Extensible-Output-Function SHAKEs" anchor="xofs">
        <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. SHAKE is a variable length hash function. 
		The output lengths, in bits, of the SHAKE hash functions is defined by the parameter d. 
		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). 
		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>	
	  </section>
	
      <section title="Mask Generation SHAKEs">
        <t>The RSASSA-PSS signature algorithm uses a mask generation function. A mask generation function 
		takes an octet string of variable length and a desired output length as input, and outputs an 
		octet string of the desired length. The mask generation function used in RSASSA-PSS is defined in 
		<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>

	    <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>
      </section>
    </section> 
	
    <section title="Signature Algorithms" anchor="rsassa-pss">
        <section title="RSASSA-PSS with SHAKEs">
           <t>The RSASSA-PSS signature algorithm identifier and its parameters are specifed in <xref target="RFC4055"/>: </t>
		    <t><figure><artwork><![CDATA[
   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }

   RSASSA-PSS-params  ::=  SEQUENCE  {
         hashAlgorithm      HashAlgorithm, 
         maskGenAlgorithm   MaskGenAlgorithm, 
         saltLength         INTEGER, 
         trailerField       INTEGER }
]]></artwork></figure></t>

		   <t>This document adds two new hash algorithm choices and two new choices for mask generation functions. 
		   These are the SHAKE128 and SHAKE256 algorithm identifiers specified in <xref target="xofs" />.</t>
           
		   <t>When SHAKE128 or SHAKE256 is used as the hashAlgorithm, it MUST also be used as the maskGenAlgorithm.</t>
		   
		   <t>When used as the hashAlgorithm, the SHAKE128 or SHAKE256 output-length must be either 32 
		   or 64 bytes respectively. In these cases, the parameters MUST be present, and they MUST employ 
		   the ShakeOutputLen syntax that contains  <!-- "MUST employ syntax borrowed from RFC4055 --> 
		   an encoded positive integer value of 32 or 64 for id-shake128-len or id-shake256-len algorithm 
		   identifier respectively.</t>
		   
		   <t>When id-shake128-len or id-shake256-len algorithm identifier is used as the id-mfg1 maskGenAlgorithm 
		   parameter, the ShakeOutputLen parameter must be (n - 264)/8 or (n - 520)/8 respectively for SHAKE128 and SHAKE256, 
		   where n is the RSA modulus in bits. For example, when RSA modulus n is 2048, ShakeOutputLen must be 223 or 191   
		   when id-shake128-len or id-shake256-len is are used respectively.</t>
		   
           <t>The parameter saltLength MUST be 32 or 64 bytes respectively for the SHAKE128 and SHA256 OIDs.</t>
           
        </section>
		
        <section title="ECDSA with SHAKEs">
          <t>The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in 
		  "Public Key Cryptography for the Financial Services Industry: The 
		  Elliptic Curve Digital Signature Standard (ECDSA)" <xref target="X9.62"/>. 
		  The ASN.1 OIDs of ECDSA signature algorithms using SHAKE128 and SHAKE256, 
		  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) x }
]]></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) y }
]]></artwork></figure></t>
		  </list></t> 
		  
		  <t> [ EDNOTE: "x" and "y" will be specified by NIST later. ]</t>
		  
		  <t>When the id-ecdsa-with-SHAKE128 or id-ecdsa-with-SHAKE256, 
		  algorithm identifier appears in the algorithm field 
		  as an AlgorithmIdentifier, the encoding MUST omit the parameters 
		  field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one 
		  component, the OID ecdsa-with-SHAKE128 or ecdsa-with-SHAKE256.</t>
		  
		  <t>Conforming CA implementations MUST specify the hash algorithm 
		  explicitly using the OIDs specified in Section 3.2 above when encoding ECDSA/SHAKE 
		  signatures in certificates and CRLs.</t>
		  
		  <t>Conforming client implementations that process ECDSA signatures with 
		  any of the SHAKE hash algorithms when processing certificates and CRLs 
		  MUST recognize the corresponding OIDs specified in Sections 3.1 and 3.2 above.</t>
		  
		  <t>Encoding rules for ECDSA signature values are specified in 
		  <xref target="RFC4055"/>, Section 2.2.3, and <xref target="RFC5480"/>.</t> 
		  
		  <t>Conforming CA implementations that generate ECDSA signatures in 
		  certificates or CRLs MUST generate such ECDSA 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 ECDSA 
		  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 above 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>		  

      	  <!-- Commenting this paragraph out, as it seems out of place to tell how to sign with ECDSA. -->
		  <!-- <t>When signing, the ECDSA algorithm generates two values.  These values 
		  are commonly referred to as r and s.  To easily transfer these two 
		  values as one signature, they MUST be ASN.1 encoded using the ECDSA-Sig-Value 
		  defined in <xref target="RFC3279"/> and repeated here for convenience:</t> 
		  <figure><artwork><![CDATA[
   ECDSA-Sig-Value ::= SEQUENCE {
       r  INTEGER,
       s  INTEGER }
]]></artwork></figure> -->
        </section>
		
        <!-- <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="Public Key Algorithms">
        <t>The conventions for RSA and ECDSA <!-- and EdDSA --> public keys are as specified in 
		<xref target="RFC3279"/>, <xref target="RFC4055"/> and <xref target="RFC5480"/><!-- and <xref target="I-D.josefsson-pkix-eddsa"/>-->.
		We include them here for convenience. </t>
		
		<t><xref target="RFC3279"/> defines the following OID for RSA with NULL parameters.</t>
		<t><figure><artwork><![CDATA[
   rsaEncryption OBJECT IDENTIFIER ::=  { pkcs-1 1}
]]></artwork></figure></t>
	    
		<t>Additionally, <xref target="RFC4055"/> adds the corresponding RSASSA-PSS OID public key 
		identifier and parameters (also shown in <xref target="rsassa-pss"/> of this document). 
		The parameters may be either absent or present when RSASSA-PSS OID is used as subject 
		public key information.</t>
	    <t><figure><artwork><![CDATA[
   id-RSASSA-PSS  OBJECT IDENTIFIER  ::=  { pkcs-1 10 }
]]></artwork></figure></t>
		
		<t>If id-RSASSA-PSS is used in the public key identifier with parameters, Section 3.3 of 
		<xref target="RFC4055"/> describes that the signature algorithm parameters MUST match the 
		parameters in the key structure algorithm identifier except the saltLength field. The 
		saltLength field in the signature parameters MUST be greater or equal to that in the key 
		parameters field. If the id-RSASSA-PSS parameters are NULL no further parameter validation 
		is necessary.</t>
		
		<t>For ECDSA, <xref target="RFC5480"/> defines the EC public key identifier and its parameters as </t>
		<t><figure><artwork><![CDATA[
   id-ecPublicKey OBJECT IDENTIFIER ::= {
       iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
	   
   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>

    <!-- 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>

    <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"/>. 
	  No further registries are required. [ 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>When more than two parties share the same message-authentication key,
      data origin authentication is not provided. Any party that knows the
      message-authentication key can compute a valid MAC, therefore the
      content could originate from any one of the parties.</t>
      
	  <t>Implementations must randomly generate message-authentication keys
      and 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 performance improves, the work factor to break a particular
      cryptographic algorithm will reduce. 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>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split into informative and normative -->

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
      <!-- &RFC2119; -->
	  &RFC3279;
	  &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; -->
	  &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>
