<?xml version="1.0" encoding="US-ASCII"?>
<!--v1 used-->
<!--
  XML2RFC offers an include feature described in the XML2RFC README
  file.  That syntax, however, contradicts the DTD requirements to
  have <reference> elements within the <references> element, so an 
  XML parser is likely to find your XML file invalid.  It may be
  possible that XML2RFC will change their DTD so that the XML file
  remains valid when their style of include is used.

  In the meantime therefore, we use an alternative valid-XML approach
  to includes, which unfortunately require that define your includes
  at the beginning of the file. Since the biggest benefit of includes
  is for references, this requires that your references be defined in
  ENTITY clauses here before being "included" and cited elsewhere in
  the file.
-->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc4492 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4492.xml">
<!ENTITY rfc5246 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml">
<!ENTITY rfc5639 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5639.xml">
<!ENTITY rfc6347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!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 rfc5480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5480.xml">
<!ENTITY rfc6090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6090.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<!--
  This template is for authors of IETF specifications containing MIB
  modules.  This template can be used as a starting point to produce
  specifications that comply with the Operations &amp; Management Area
  guidelines for MIB module documents.
-->
<!--
  Throughout this template, the marker "<xref target='TODO' />" is used to indicate an
  element or text that requires replacement or removal.
-->
<!-- Intellectual Property section -->
<!--
  The Intellectual Property section will be generated automatically by
  XML2RFC, based on the ipr attribute in the rfc element.
-->
<!-- 

<xref target='TODO' />For Internet-drafts, indicate which intellectual property notice 
to use per the rules of RFC3978.
Specify this in the ipr attribute.  The value can be:
    full3978 -
    noModification3978 -
    noDerivatives3978 -
<xref target='TODO' /> Specify the category attribute per RFC2026 
options are info, std, bcp, or exp.
<xref target='TODO' /> if this document updates an RFC, specify the RFC in the 
"updates" attribute
-->

<rfc category="info" updates="4492" submissionType="IETF" consensus="yes" ipr="trust200902" number="7027" >
     
  <front>
    
    <title abbrev="ECC Brainpool Curves for TLS">Elliptic Curve Cryptography
(ECC) Brainpool Curves for Transport Layer Security (TLS)</title>

 
    <!-- see RFC2223 for guidelines regarding author names -->

    <author fullname="Johannes Merkle" initials="J.M." 
            surname="Merkle">
      <organization>secunet Security Networks</organization>

      <address>
        <postal>
          <street>Mergenthaler Allee 77</street>

          <city>65760 Eschborn</city>

          <country>Germany</country>
        </postal>

        <phone>+49 201 5454 3091</phone>

        <email>johannes.merkle@secunet.com</email>
      </address>
    </author>
    
    <author fullname="Manfred Lochter" initials="M.L." 
            surname="Lochter">
      <organization abbrev="BSI">Bundesamt fuer Sicherheit in der Informationstechnik (BSI)</organization>

      <address>
        <postal>
          <street>Postfach 200363</street>

          <city>53133 Bonn</city>

          <country>Germany</country>
        </postal>

        <phone>+49 228 9582 5643</phone>

        <email>manfred.lochter@bsi.bund.de</email>
      </address>
    </author>

    
    <!-- <xref target='TODO' />: month and day will be generated automatically by XML2RFC; 
be sure the year is current.
-->

    <date month="September" year="2013" />


    <workgroup></workgroup>

    <keyword>TLS, Elliptic Curve Cryptography</keyword>


    <abstract>
    <t>This document specifies the use of several Elliptic Curve Cryptography (ECC) Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol.</t>
    </abstract>

  </front>

  
  <middle>
    <section title="Introduction">

  <t><xref target='RFC5639' /> specifies a new set of elliptic curve groups over
   finite prime fields for use in cryptographic applications. These groups, denoted as ECC Brainpool curves, were generated in a verifiably pseudo-random way and comply with the security requirements of relevant standards from ISO <xref target='ISO1' /> <xref target='ISO2' />, ANSI <xref target='ANSI1' />, NIST <xref target='FIPS' />, and SecG <xref target='SEC2' />. </t>
      
  
   <t><xref target='RFC4492' /> defines the usage of elliptic curves for
authentication and key agreement in TLS 1.0 and TLS 1.1; these mechanisms
may also be used with TLS 1.2 <xref target='RFC5246' />. 
While the ASN.1
object identifiers defined in <xref target='RFC5639' /> already allow usage of
the ECC Brainpool curves for TLS (client or server) authentication through reference in X.509 certificates according to <xref target='RFC3279' /> and <xref target='RFC5480' />, their negotiation for key exchange according to <xref target='RFC4492' /> requires the definition and assignment of additional NamedCurve IDs. This document specifies such values for three curves from <xref target='RFC5639' />.</t>

   </section>

<!--   <section title="Requirements Terminology">

   <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 RFC 2119 <xref target='RFC2119' /> </t>.
   </section>
-->
 
  
 <section anchor="Main" title="Brainpool NamedCurve Types">

<t>According to <xref target='RFC4492' />, the name space NamedCurve is used for the negotiation of elliptic curve groups for key exchange during a handshake starting a new TLS session. This document adds new NamedCurve types to three elliptic curves defined in <xref target='RFC5639' /> as follows:</t>


<figure>
<artwork><![CDATA[
        enum {
             brainpoolP256r1(26),
             brainpoolP384r1(27),
             brainpoolP512r1(28)
        } NamedCurve;
]]></artwork>
</figure>

<t>These curves are suitable for use with Datagram TLS <xref target='RFC6347' />.</t>
<t>Test vectors for a Diffie-Hellman key exchange using these elliptic curves are provided in <xref target='test_vectors' />.</t>
</section>

  <section title="IANA Considerations">
  <t>   IANA has assigned numbers for the ECC Brainpool curves listed in 
<xref target='Main' /> in the "EC Named Curve <xref target='IANA-TLS' />
registry of the "Transport Layer Security (TLS) Parameters" registry as follows: </t>

 <texttable anchor='namedCurves'>
  <preamble></preamble>
  <ttcol align='center'>Value</ttcol>
  <ttcol align='center'>Description</ttcol>
  <ttcol align='center'>DTLS-OK</ttcol>
  <ttcol align='center'>Reference</ttcol>
  <c>26</c>
  <c>brainpoolP256r1</c>
    <c>Y</c>
  <c>RFC 7027</c>
  <c>27</c>
  <c>brainpoolP384r1</c>
    <c>Y</c>
  <c>RFC 7027</c>
  <c>28</c>
  <c>brainpoolP512r1</c>
  <c>Y</c>
  <c>RFC 7027</c>
<postamble></postamble>
</texttable>

  </section>

   <section anchor="Security" title="Security Considerations">
   <t>The security considerations of <xref target='RFC5246' /> apply
to the ECC Brainpool curves described in this document.
</t>
    <t>The confidentiality, authenticity, and integrity of the TLS
communication is limited by the weakest cryptographic primitive applied. In
order to achieve a maximum security level when using one of the elliptic curves
from <xref target='namedCurves' /> for authentication and/or key exchange in
TLS, the key derivation function; the algorithms and key lengths of symmetric
encryption; and message authentication (as well as the algorithm, bit length, and
hash function used for signature generation) should be chosen according to the
recommendations of <xref target="NIST800-57"/> and <xref
target="RFC5639"/>. Furthermore, the private Diffie-Hellman keys should be
selected with the same bit length as the order of the group generated by the
base point G and with approximately maximum entropy.</t>  

    
	<t>Implementations of elliptic curve cryptography for TLS may be susceptible to side-channel attacks.  Particular care should be taken for implementations that internally transform curve points to points on the corresponding "twisted curve", using the map (x',y') = (x*Z^2, y*Z^3) with the coefficient Z specified for that curve in <xref target='RFC5639' />, in order to take advantage of an efficient arithmetic based on the twisted curve's special parameters (A = -3). Although the twisted curve itself offers the same level of security as the corresponding random curve (through mathematical equivalence), an arithmetic based on small curve parameters may be harder to protect against side-channel attacks. General guidance on resistance of elliptic curve cryptography implementations against side-channel-attacks is given in <xref target='BSI1' /> and <xref target="HMV"/>.</t>

  </section>

      

    
 
  
  
    <!-- The Author's Addresses section will be generated automatically by XML2RFC from the front information -->

  </middle>
  
  
  

  <back>
    <!-- References Section -->

    <!-- Section 4.7f of <xref target='RFC2223bis' /> specifies the requirements for the
   references sections.  In particular, there MUST be separate lists of
   normative and informative references, each in a separate section.
   The style SHOULD follow that of recently published RFCs.

   The standard MIB boilerplate available at
   http://www.ops.ietf.org/mib-boilerplate.html includes lists of
   normative and informative references that MUST appear in all IETF
   specifications that contain MIB modules.  If items from other MIB
   modules appear in an IMPORTS statement in the Definitions section,
   then the specifications containing those MIB modules MUST be included
   in the list of normative references.  When items are imported from an
   IANA-maintained MIB module the corresponding normative reference
   SHALL point to the on-line version of that MIB module.  It is the
   policy of the RFC Editor that all references must be cited in the
   text;  such citations MUST appear in the overview section where
   documents containing imported definitions (other those already
   mentioned in the MIB boilerplate) are required to be mentioned (cf.
   Section 3.2).

In general, each normative reference SHOULD point to the most recent
version of the specification in question.
-->

<references title="Normative References">

      
<reference anchor="IANA-TLS" target="http://www.iana.org/assignments/tls-parameters">
      <front>
      <title>Transport Layer Security (TLS) Parameters</title>
      <author>
      <organization>Internet Assigned Numbers Authority</organization>
      </author>
      <date month="" year=""/>
      </front>
</reference>    

<!-- rfc include="reference.RFC.2119" -->
<?rfc include="reference.RFC.4492" ?>
<?rfc include="reference.RFC.5246" ?>
<?rfc include="reference.RFC.5639" ?>      
<?rfc include="reference.RFC.6347" ?>
      
</references>

<references title="Informative References">

      <reference anchor="ANSI1">
      <front>
      <title>
      Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)
      </title>
      <author>
      <organization>American National Standards Institute</organization>
      </author>
      <date month="" year="2005"/>
      </front>
      <seriesInfo name="ANSI" value="X9.62"/>
      </reference>
      
      
       <reference anchor="BSI1">
      <front>
      <title>Minimum Requirements for Evaluating Side-Channel Attack Resistance of Elliptic Curve Implementations
       </title>
      <author>
      <organization>Bundesamt fuer Sicherheit in der Informationstechnik</organization>
      </author>
      <date month="July" year="2011"/>
      </front>
      </reference>   
      
  
     <reference anchor="FIPS">
      <front>
      <title>Digital Signature Standard (DSS)</title>
      <author>
      <organization>National Institute of Standards and Technology</organization>
      </author>
      <date month="December" year="1998" />
      </front>
      <seriesInfo name="FIPS" value="PUB 186-2" />
      </reference>
      
      <reference anchor="HMV">
      <front>
      <title>
      Guide to Elliptic Curve Cryptography
      </title>
      <author initials="D" surname="Hankerson">
      <organization>
      </organization>
      </author>
      <author initials="A" surname="Menezes">
      <organization>
      </organization>
      </author>
      <author initials="S" surname="Vanstone">
      <organization>
      </organization>
      </author>
      <date month="" year="2004"/>
      </front>
      <seriesInfo name="Springer" value="Verlag"/>
      </reference>

      
      
      <reference anchor="ISO1">
      <front>
      <title>
      Information Technology - Security Techniques - Digital Signatures with Appendix - Part 3: Discrete Logarithm Based Mechanisms
      </title>
      <author>
      <organization>International Organization for Standardization      </organization>
      </author>
      <date month="" year="2006"/>
      </front>
      <seriesInfo name="ISO/IEC" value="14888-3"/>
      </reference>

      
      <reference anchor="ISO2">
      <front>
      <title>
      Information Technology - Security Techniques - Cryptographic Techniques Based on Elliptic Curves - Part 2: Digital signatures
      </title>
      <author>
      <organization>International Organization for Standardization      </organization>
      </author>
      <date month="" year="2002"/>
      </front>
      <seriesInfo name="ISO/IEC" value="15946-2"/>
      </reference>   

      <reference anchor="NIST800-57">
      <front>
      <title>
      Recommendation for Key Management - Part 1: General (Revised) 
      </title>
      <author>
      <organization>National Institute of Standards and Technology</organization>
      </author>
      <date month="March" year="2007"/>
      </front>
      <seriesInfo name="NIST Special Publication" value="800-57"/>
      </reference>        
      
<?rfc include="reference.RFC.3279" ?>      
<?rfc include="reference.RFC.5480" ?>      

      <reference anchor="SEC1">
      <front>
      <title>
      Elliptic Curve Cryptography
      </title>
      <author>
      <organization>Certicom Research 
      </organization>
      </author>
      <date month="September" year="2000"/>
      </front>
      <seriesInfo name="Standards for Efficient Cryptography (SEC)" value="1"/>
      </reference>
        

      <reference anchor="SEC2">
      <front>
      <title>
      Recommended Elliptic Curve Domain Parameters
      </title>
      <author>
      <organization>Certicom Research 
      </organization>
      </author>
      <date month="September" year="2000"/>
      </front>
      <seriesInfo name="Standards for Efficient Cryptography (SEC)" value="2"/>
      </reference>
      
    </references>

    
    <section anchor="test_vectors" title="Test Vectors">
    
    <t>This section provides some test vectors for example Diffie-Hellman
   key exchanges using each of the curves defined in 
<xref target="namedCurves"/>. The following notation is used in the subsequent
sections: 
   <list>

   <t>  d_A: the secret key of party A </t>

   <t>  x_qA: the x-coordinate of the public key of party A </t>

   <t>  y_qA: the y-coordinate of the public key of party A </t>

   <t>  d_B: the secret key of party B </t>

   <t>  x_qB: the x-coordinate of the public key of party B </t>

   <t>  y_qB: the y-coordinate of the public key of party B </t>

   <t>  x_Z: the x-coordinate of the shared secret that results from
      completion of the Diffie-Hellman computation, i.e., the hex representation of the pre-master secret</t>

   <t>  y_Z: the y-coordinate of the shared secret that results from
      completion of the Diffie-Hellman computation </t>
</list> 
The field elements x_qA, y_qA, x_qB, y_qB, x_Z, and y_Z are represented as hexadecimal values using the FieldElement-to-OctetString conversion method specified in <xref target='SEC1' />.
</t>


<section title="256 Bit Curve">

  <t>Curve brainpoolP256r1
   <list>
    <t>dA =   81DB1EE100150FF2EA338D708271BE38300CB54241D79950F77B063039804F1D </t>

    <t>x_qA = 44106E913F92BC02A1705D9953A8414DB95E1AAA49E81D9E85F929A8E3100BE5 </t>
    <t>y_qA = 8AB4846F11CACCB73CE49CBDD120F5A900A69FD32C272223F789EF10EB089BDC </t>

    <t>dB =   55E40BC41E37E3E2AD25C3C6654511FFA8474A91A0032087593852D3E7D76BD3 </t>

    <t>x_qB = 8D2D688C6CF93E1160AD04CC4429117DC2C41825E1E9FCA0ADDD34E6F1B39F7B </t>
    <t>y_qB = 990C57520812BE512641E47034832106BC7D3E8DD0E4C7F1136D7006547CEC6A </t>

    <t>x_Z =  89AFC39D41D3B327814B80940B042590F96556EC91E6AE7939BCE31F3A18BF2B </t>
    <t>y_Z =  49C27868F4ECA2179BFD7D59B1E3BF34C1DBDE61AE12931648F43E59632504DE	 </t>	
</list></t>
  
   </section>


   <section title="384 Bit Curve">

   <t>Curve brainpoolP384r1
   <list>
    <t>dA =   1E20F5E048A5886F1F157C74E91BDE2B98C8B52D58E5003D57053FC4B0BD65D6F15EB5D1EE1610DF870795143627D042 </t>

    <t>x_qA = 68B665DD91C195800650CDD363C625F4E742E8134667B767B1B476793588F885AB698C852D4A6E77A252D6380FCAF068 </t>
    <t>y_qA = 55BC91A39C9EC01DEE36017B7D673A931236D2F1F5C83942D049E3FA20607493E0D038FF2FD30C2AB67D15C85F7FAA59 </t>

    <t>dB =   032640BC6003C59260F7250C3DB58CE647F98E1260ACCE4ACDA3DD869F74E01F8BA5E0324309DB6A9831497ABAC96670 </t>

    <t>x_qB = 4D44326F269A597A5B58BBA565DA5556ED7FD9A8A9EB76C25F46DB69D19DC8CE6AD18E404B15738B2086DF37E71D1EB4 </t>
    <t>y_qB = 62D692136DE56CBE93BF5FA3188EF58BC8A3A0EC6C1E151A21038A42E9185329B5B275903D192F8D4E1F32FE9CC78C48 </t>

    <t>x_Z = 0BD9D3A7EA0B3D519D09D8E48D0785FB744A6B355E6304BC51C229FBBCE239BBADF6403715C35D4FB2A5444F575D4F42 </t>
    <t>y_Z = 0DF213417EBE4D8E40A5F76F66C56470C489A3478D146DECF6DF0D94BAE9E598157290F8756066975F1DB34B2324B7BD </t>
</list></t>

   </section>
   
<section title="512 Bit Curve">

   <t>Curve brainpoolP512r1
   <list>
    <t>dA =   16302FF0DBBB5A8D733DAB7141C1B45ACBC8715939677F6A56850A38BD87BD59B09E80279609FF333EB9D4C061231FB26F92EEB04982A5F1D1764CAD57665422 </t>

    <t>x_qA = 0A420517E406AAC0ACDCE90FCD71487718D3B953EFD7FBEC5F7F27E28C6149999397E91E029E06457DB2D3E640668B392C2A7E737A7F0BF04436D11640FD09FD  </t>
    <t>y_qA = 72E6882E8DB28AAD36237CD25D580DB23783961C8DC52DFA2EC138AD472A0FCEF3887CF62B623B2A87DE5C588301EA3E5FC269B373B60724F5E82A6AD147FDE7 </t>
   
    <t>dB =   230E18E1BCC88A362FA54E4EA3902009292F7F8033624FD471B5D8ACE49D12CFABBC19963DAB8E2F1EBA00BFFB29E4D72D13F2224562F405CB80503666B25429 </t>
   
    <t>x_qB = 9D45F66DE5D67E2E6DB6E93A59CE0BB48106097FF78A081DE781CDB31FCE8CCBAAEA8DD4320C4119F1E9CD437A2EAB3731FA9668AB268D871DEDA55A5473199F  </t>
    <t>y_qB = 2FDC313095BCDD5FB3A91636F07A959C8E86B5636A1E930E8396049CB481961D365CC11453A06C719835475B12CB52FC3C383BCE35E27EF194512B71876285FA	 </t>	
   
    <t>x_Z =  A7927098655F1F9976FA50A9D566865DC530331846381C87256BAF3226244B76D36403C024D7BBF0AA0803EAFF405D3D24F11A9B5C0BEF679FE1454B21C4CD1F  </t>
    <t>y_Z =  7DB71C3DEF63212841C463E881BDCF055523BD368240E6C3143BD8DEF8B3B3223B95E0F53082FF5E412F4222537A43DF1C6D25729DDB51620A832BE6A26680A2 </t>
</list></t>

  </section>
   
  </section>



   
  </back>
</rfc>
