<?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 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC4880 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml'>
<!ENTITY RFC6637 PUBLIC '' 'http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6637.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-jivsov-openpgp-sha3-01" ipr="trust200902">
  <!-- 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="SHA-3 in OpenPGP">The use of Secure Hash Algorithm 3 in OpenPGP</title>

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

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

    <author fullname="Andrey Jivsov" initials="A.J." surname="Jivsov">

      <organization>F5 Networks, Inc.</organization>

      <address>
<!--
        <postal>
          <street></street>
          <city>Soham</city>
          <region></region>
          <code></code>
          <country>UK</country>
        </postal>
        <phone>+44 7889 488 335</phone>
-->
        <email>openpgp@brainhub.org</email>

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

    </author>

    <date year="2015" />

    <!-- 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>Network Workign Group</workgroup>
    
	<keyword>SHA-3</keyword>
	<keyword>Keccak</keyword>
	<keyword>hash</keyword>
	<keyword>digest</keyword>
	<keyword>Secure Hash Algorithm</keyword>
	<keyword>OpenPGP</keyword>
	<keyword>digital signature</keyword>
	<keyword>cryptography</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 presents the necessary information to implement the SHA-3 hash algorithm with the OpenPGP format.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
	<t>
		The OpenPGP format <xref target="RFC4880"></xref> supports multiple hash algorithms.  This document provides 
		the necessary information to use the Secure Hash Algorithm-3 (SHA-3) with the OpenPGP format.
	</t>
	<t>
		National Institute of Standards and Technology (NIST) selected <xref target="Keccak" /> for its elegant design, 
		its efficiency on various computing devices, high performance in hardware implementations, and different internal 
		structure that may provide better defense against attacks on its predecessors from the SHA-1 and SHA-2 family. 
		<xref target="SHA-3" /> specification is an instantiation of the <xref target="Keccak" /> algorithm.
	</t>

	</section>

	<section title="Conventions used in this document">
	<t>
		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
		document are to be interpreted as described in <xref
		target="RFC2119"/>.
	</t>
	</section>


	<section title="Overview of the hash algorithm use in OpenPGP" anchor="md_overview">
        <t>
		Hash algorithm is used in <xref target="RFC4880"/> with digital signatures, with modification detection code, and to calculate key fingerprints. 
		Only digital signatures allow algorithm agility and are most vulnerable to various attacks on hash functions. The focus of this document 
		is on the use of SHA-3 hash with OpenPGP digital signatures.
	</t>
	<t>
		The use of hash algorithm with digital signatures in OpenPGP falls into two categories. The first one is the digital signatures over messages, 
		and another one is the certifications of the key material. The key certifications includes self-signatures, which convey key preference information, 
		among other tasks. The rest of key certifications are third party key signatures. These categories are considered separately     
		in <xref target="interop"/> for their impact on interoperability.
        </t>
	</section>

	<section title="Supported SHA-3 algorithms">
	<t>
		SHA-3 specification <xref target="SHA-3" /> defines a single cryptographic hash function that is parameterized to produce hash output of a specific size. This document
		refers to these instantiations of the same hash algorithm as SHA-3 hash algorithms and treats them as different hash algorithms with unique IDs.
	</t>
	<t>
		The SHA-3 algorithm SHA3-256, SHA3-384, and SHA3-512, which has the output size of 256, 384, and 512 bits, respectively, MAY be used as a hash algorithm with digital signatures.
	</t>
	<t> 
		The input size to the hash algorithm in OpenPGP MUST be a multiple of 8 bits. In more details, <xref target="SHA-3" /> provides domain separation for different 
		instantiations of <xref target="Keccak" /> by adding two bits 01 to a message-to-be-hashed M. M is what gets hashed with other hash algorithms, such as SHA2-256,
		and the length of M MUST be a multiple of 8 bits. The hashing of 01 bits can be integrated into the finalization stage of a SHA-3 implementation. 
		A sample implementation <xref target="SHA3IUF"/> demonstrates how to do this with Init/Update/Finalize style of hashing API. 
	</t>
	<t>
		An application MAY generate signatures with SHA3-256, SHA3-384, and SHA3-512 hash algorithms. An application MUST implement signature verification for three SHA-3 algorithms 
		if it implements at least one of the SHA-3 algorithms.  
		The all-or-nothing requirement should be feasible for the vast majority of implementations because it is relatively easy to implement all SHA-3 algorithms with a single unified implementation, 
		as <xref target="SHA3IUF"/> demonstrates, where the only variable that distinguishes these algorithms is an integer representing the the capacity parameter of the Keccak. 
	</t>
	<t>
		Applications MAY use any digital signature algorithm described in <xref target="RFC4880"/> and Elliptic Curve DSA algorithm described in <xref target="RFC6637" /> with SHA-3.
	</t>

	</section>

	<section title="Use with RSA digital signatures">
	<t>
		Section 5.2.2 of <xref target="RFC4880"/> describes the Version 3 Signature Packet Format. One of the allowed public key algorithms in 
		that section is the RSA digital signature algorithm. RSA signatures use the PKCS#1 encoding to format (cryptographically "pad") the 
		output of the hash algorithm. The padding includes the DER-encoded prefix that is fixed for the given hash 
		algorithm.  While this prefix is a DER encoding of an ASN.1 Object Identifier (OID), the length of the hash output, 
		and the supporting fields, it's possible to define the prefix as a fixed sequence of octets.  These prefixes are defined below. 
	</t>

	<texttable style="headers" title="SHA-3 hash OIDs">

          <ttcol width="20%" align="left">Algorithm</ttcol>
          <ttcol width="80%" align="left">ASN.1 OID</ttcol>

          <c>SHA3-256</c>
          <c>2.16.840.1.101.3.4.2.8</c>

          <c>SHA3-384</c>
          <c>2.16.840.1.101.3.4.2.9</c>

          <c>SHA3-512</c>
          <c>2.16.840.1.101.3.4.2.10</c>
        </texttable>

	<t>
		 The full DER-encoded hash prefixes are provided bellow.
	</t>

        <texttable style="headers" title="SHA-3 hash full DER prefixes">
          <ttcol width="20%" align="left">Algorithm</ttcol>
          <ttcol width="80%" align="left">Full DER prefix</ttcol>

          <c>SHA3-256</c>
          <c>30,31,30,0d, 06,09,60,86, 48,01,65,03, 04,02,08,05, 00,04,20 [32-octet hash]</c>

          <c>SHA3-384</c>
          <c>30,41,30,0d, 06,09,60,86, 48,01,65,03, 04,02,09,05, 00,04,30 [48-octet hash]</c>

          <c>SHA3-512</c>
          <c>30,51,30,0d, 06,09,60,86, 48,01,65,03, 04,02,0a,05, 00,04,40 [64-octet hash]</c>
        </texttable>

	</section>

	<section title="Interoperability concerns arising from an introduction of a new hash algorithm" anchor="interop">

	<t>
		The use of a new hash algorithm in a public key certifications, especially in self-signatures, can make the key unusable in the 
		large extent of the OpenPGP ecosystem.  The impact of the use of the new hash algorithm in a digital signature over a message is 
		limited to users who will be verifying this message.
	</t>

	<t>
		Implementation MUST include SHA-3 algorithms in the Hash Algorithm Preferences of the keys it generates when it updates the algorithm preferences.
		This preference is described in the Section 13.3.2 of <xref target="RFC4880"/>.
	</t>
	<t>
		In cases when the message is both encrypted and signed, the application knows the keys of the entities who will be performing signature verification. 
		The application SHOULD rely on Hash Algorithm Preferences of the recipients' public keys to learn about SHA-3 support.
	</t>

	<t>
		Addition of the SHA-3 support will benefit from planning ahead.
	</t>
<!--
	<t>
		Interoperability concerns arising from the introduction of SHA-3 are not unique to SHA-3. For example, exactly the same concerns also apply during the introduction of a new digital signature algorithm. 
		Informally speaking, these concerns are a result of creating data structures that will be processed by unknown parties 
		at an undetermined future moment.
	</t>
-->
	<t>
		The digital signature validation is dependent on wide support of the selected hash algorithm by deployed 
		OpenPGP implementations that will be verifying the digital signature. In general, there is no method in OpenPGP by which a party that 
		issues a digital signature can be certain about the support of a hash algorithm by other implementations. 
	</t>	
	<t>
		The safest method to mitigate these challenges is a phased deployment of the new hash algorithm support in the application, as follows:
	</t>	
	<t>
		<list style="symbols">
			<t>Implement the hash algorithm, test it thoroughly.</t>
			<t>Enable its use with the digital signature algorithms and test signature generation and verification, ideally, with multiple implementations. 
			Then disable the signature generation in the released code (i.e. leave the "read support" only).</t>
			<t>Wait sufficiently long for the deployment of the applications that can verify digital signatures with the new hash algorithm.</t>
			<t>Enable the generation of signatures with the new hash algorithm, starting from the signatures over messages, later extending it to certifications.</t>
		</list> 
	</t>
	</section>

<!--
    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This template was derived from an initial version written by Pekka
      Savola and contributed by him to the xml2rfc project.</t>

      <t>This document is part of a plan to make xml2rfc indispensable <xref
      target="DOMINATION"></xref>.</t>
    </section>
-->

    <section anchor="IANA" title="IANA Considerations">
	<t>This document asks to allocate the consecutive hash algorithm IDs from the Hash Algorithm ID range, defined in the Section 9.4 of <xref target="RFC4880"/>.</t>
	<t>The starting ID is not important, but the properties that the IDs are sequential and in the given order are expected to simplify implementation.</t>

        <texttable style="headers" anchor="IDs" title="SHA-3 hash IDs">

          <ttcol width="8%" align="center">ID</ttcol>
          <ttcol width="40%" align="left">Algorithm</ttcol>
          <ttcol width="10%" align="left">Text Name</ttcol>

          <c>13</c>
          <c>SHA-3 with 256 bit output</c>
          <c>"SHA3-256"</c>

          <c>14</c>
          <c>SHA-3 with 384 bit output</c>
          <c>"SHA3-384"</c>

          <c>15</c>
          <c>SHA-3 with 512 bit output</c>
          <c>"SHA3-512"</c>
        </texttable>
    </section>

    <section anchor="Security" title="Security Considerations">
	<t>
		SHA-3 hash algorithms have different internal structure, informally called "wide pipe" or "sponge" design, that may offer higher security in the future over the strength of its SHA-2 predecessors with
		identical output size, especially with digital signature applications. 
	</t>
	<t>
		Table 2 from <xref target="SP800-57"/> SHOULD be used to determine the corresponding strength of the public key algorithm for the given hash algorithm.
		For example, the SHA-3 256 has equivalent security strength to the NIST curve P-256 <xref target="RFC6637" />. 
		Refer to Table 4 in section A.1 <xref target="SHA-3" /> for security strength of the SHA-3 algorithms.
	</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;
      &RFC4880;

      <reference anchor="SHA-3" target="http://dx.doi.org/10.6028/NIST.FIPS.202">  
        <front> 
		<title> 
			SHA-3 STANDARD: PERMUTATION-BASED HASH AND EXTENDABLE OUTPUT FUNCTIONS 
		</title>
          <author>
		<organization>NIST</organization>
          </author>

          <date year="2015" month="August" />
        </front>
      </reference>

    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <reference anchor="Keccak" target="http://http://keccak.noekeon.org/">
        <front>
          <title>The Keccak sponge function family</title>
		<author initials="G" surname="Bertoni"></author> 
		<author initials="J" surname="Daemen"></author> 
		<author initials="M" surname="Peeters"></author> 
		<author initials="G" surname="Van Assche"></author> 
          <date year="2012" />
        </front>
      </reference>

      &RFC6637;

      <!-- A reference written by by an organization not a person. -->
<!--
      <reference anchor="Announcement"
                 target="http://www.nist.gov/itl/csd/sha-100212.cfm">
        <front>
          <title>NIST Selects Winner of Secure Hash Algorithm (SHA-3) Competition</title>
          <author>
            <organization>NIST</organization>
          </author>

          <date year="2012" month="October" day="2" />
        </front>
      </reference>
-->

      <reference anchor="SP800-57" target="http://csrc.nist.gov/publications/PubsSPs.html">
        <front>
		<title>
			Recommendation for Key Management -- Part 1: General (Revision 3)
		</title>
	<author>
		<organization>NIST</organization>
	</author>

          <date year="2012" month="July" />
        </front>
      </reference>

      <reference anchor="SHA3IUF" target="https://github.com/brainhub/SHA3IUF">
        <front>
		<title>
			A single-file C implementation of SHA-3 with IUF API
		</title>
	<author initials="A" surname="Jivsov" fullname="Andrey Jivsov"> 
		<organization>self</organization>
	</author>

          <date year="2015" month="August" />
        </front>
      </reference>


<!--
      <reference anchor="AES" target="http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf">
        <front> 
		<title> 
			Specification for the ADVANCED ENCRYPTION STANDARD (AES)
		</title>
          <author>
		<organization>NIST</organization>
          </author>

          <date year="2001" month="November" day="26" />
        </front>
      </reference>
-->
    </references>
<!--
    <section anchor="app-additional" title="Additional Stuff">
      <t>This becomes an Appendix.</t>
    </section>
-->
  </back>
</rfc>
