<?xml version="1.0" encoding="US-ASCII"?>

<!--
  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 rfc2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc4181 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4181.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2578 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2578.xml">
<!ENTITY rfc2579 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2579.xml">
<!ENTITY rfc2580 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2580.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
]>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc strict="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" docName="draft-merkle-ikev2-ke-brainpool-05" 
   ipr="trust200902">
     
  <front>
    
    <title abbrev="Brainpool Curves for IKEv2 Key Exchange">Using the ECC Brainpool Curves for IKEv2 Key Exchange</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>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 year="2013" />


    <workgroup></workgroup>

    <keyword>IKE, Elliptic Curve</keyword>

  

    <abstract>
    <t>This document specifies the use of ECC Brainpool elliptic curve groups for key exchange in the Internet Key Exchange version 2 (IKEv2) protocol.</t>
    </abstract>

  </front>

  
  <middle>
    <section title="Introduction">

  <t>In <xref target='RFC5639' />, a new set of elliptic curve groups over
   finite prime fields for use in cryptographic applications was specified. 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>While the ASN.1 object identifiers defined in RFC 5639 allow usage of the ECC Brainpool curves in certificates and certificate revocation lists, their utilization for key exchange in IKEv2 <xref target='RFC5996' /> requires the definition and assignment of additional Diffie-Hellman Group Transform IDs in the respective IANA registry. This document specifies tranform IDs for four curves from RFC 5639 as well as the encoding of the key exchange payload and derivation of the shared secret when using one of these curves.</t>
 
    <section title="Requirements Language">
    <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>

   
 
  <section anchor="Spec" title="IKEv2 Key Exchange using the ECC Brainpool Curves">
  
  <section anchor="IDs" title="Diffie-Hellman Group Transform IDs">      
     <t>In order to use the ECC Brainpool curves for key exchange within IKEv2, the Diffie-Hellman Group Transform IDs (Transform Type 4) listed in the following table are to be registered with IANA <xref target='IANA-IKE2' />. The parameters associated with these curves are defined in RFC 5639 <xref target='RFC5639' />.</t>       
 
  <texttable anchor='transformIDs'>
  <preamble></preamble>
  <ttcol align='center'>Curve</ttcol>
  <ttcol align='center'>Transform ID</ttcol>
  <c>brainpoolP224r1</c>
  <c>27</c>
  <c>brainpoolP256r1</c>
  <c>28</c>
  <c>brainpoolP384r1</c>
  <c>29</c>
  <c>brainpoolP512r1</c>
  <c>30</c>
<postamble></postamble>
</texttable>

<t>Test vectors for the groups defined by the ECC Brainpool curves are provided in <xref target='test_vectors' /></t>
 </section>
 

        <section anchor="twisted" title="Using the Twisted Brainpool Curves Internally">

<t>In <xref target='RFC5639' /> for each random curve, a "twisted curve" (defined by a quadratic twist, see <xref target="HMV"/>) is defined offering the same level of security but potentially allowing more efficient arithmetic due to the curve parameter A = -3. The transform IDs listed in <xref target='transformIDs' /> also allow using the twisted curve corresponding to the specified random curve: points (x,y) of any curve listed in  can be efficiently transformed to the corresponding point (x',y') on the twisted curve of same bit length - and vice versa - by setting (x',y') = (x*Z^2, y*Z^3) with the coefficient Z specified for that curve in <xref target='RFC5639' />.</t>

 </section>
 
        <section anchor="encoding" title="Key Exchange Payload and Shared Secret">
          
         <t>For the encoding of the key exchange payload and the derivation of the shared secret, the methods specified in <xref target='RFC5903' /> are adopted.</t>

    <t>In an ECP key exchange in IKEv2, the Diffie-Hellman public value passed in a KE payload consists of two components, x and y, corresponding to the coordinates of an elliptic curve point. 
   Each component MUST be computed from the corresponding coordinate using the FieldElement-to-OctetString conversion method specified in <xref target='SEC1' /> and MUST have bit length as indicated in  
   <xref target='bitlengths' />.  This length is enforced by the FieldElement-to-OctetString conversion method, if necessary, by prepending the value with zeros.</t>

   <t>Note: The FieldElement-to-OctetString conversion method specified in <xref target='SEC1' /> is equivalent to applying the conversion between integers and octet strings of Section 6 of  <xref target='RFC6090' /> after representing the field element as integer in the interval [0, p-1].</t>
   
     <texttable anchor='bitlengths'>
  <preamble></preamble>
  <ttcol align='center'>Curves</ttcol>
  <ttcol align='center'>Bit length of each component (x or y)</ttcol>
  <ttcol align='center'>Bit length of key exchange payload</ttcol>
   <c>brainpoolP224r1</c>
  <c>224</c><c>448</c>
  <c>brainpoolP256r1</c>
  <c>256</c><c>512</c>  
  <c>brainpoolP384r1</c>
  <c>384</c><c>768</c>  
  <c>brainpoolP512r1</c>
  <c>512</c><c>1024</c> 
<postamble></postamble>
</texttable>
   
  
   <t>From these components, the key exchange payload MUST be computed as the concatenation of the x and y coordinates. Hence, the key exchange payload has the bit length indicated in <xref target='bitlengths' />. </t>
   
   
           
    <t>The Diffie-Hellman shared secret value consists only of the x value. In particular, the shared secret value MUST be computed from the x coordinate of the
   Diffie-Hellman common value using the FieldElement-to-OctetString conversion method specified in <xref target='SEC1' /> and MUST have bit length as indicated in the <xref target='bitlengths' />. </t>
   
     
   </section>
   </section>


   <section anchor="Security" title="Security Considerations">
   
   <t>The security considerations of <xref target="RFC5996"/> apply accordingly.</t>
   <t>In order to thwart certain active attacks, the validity of the other peer's public Diffie-Hellmann value (x,y) recovered from the received key exchange payload needs to be verified. In particular, it must be verified that the coordinates x and y of the public value satisfy the curve equation.</t>
       <t>The confidentiality, authenticity and integrity of a secure communication based on IKEv2 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='transformIDs' /> for key exchange, 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 IKEv2 could be susceptible to side-channel attacks.  Particular care should be taken for implementations that internally use the corresponding twisted curve to take advantage of an efficient arithmetic for the 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 could be harder to protect against side-channel attacks. General guidance on resistence of elliptic curve cryptography implementations against side-channel-attacks is given in <xref target='BSI1' /> and <xref target="HMV"/>.</t>
       
  </section>





  

  <section title="IANA Considerations">
  <t> IANA has updated its Transform Type 4 (Diffie-Hellman Group Transform) registry in <xref target='IANA-IKE2' /> to include the groups listed in <xref target='transformIDs' />.    </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-IKE2" target="http://www.iana.org/assignments/ikev2-parameters">
      <front>
      <title>Internet Key Exchange Version 2 (IKEv2) Parameters</title>
      <author>
      <organization>Internet Assigned Numbers Authority</organization>
      </author>
      <date month="" year=""/>
      </front>
      </reference>    
    
      
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
</front>

<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>

<reference anchor='RFC5996'>
<front>
<title>Internet Key Exchange Protocol Version 2 (IKEv2)</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='Y.' surname='Nir' fullname='Y. Nir'>
<organization /></author>
<author initials='P.' surname='Eronen' fullname='P. Eronen'>
<organization /></author>
<date year='2010' month='September' />
</front>
<seriesInfo name='RFC' value='5996' />
<format type='TXT' octets='346466' target='http://www.rfc-editor.org/rfc/rfc5996.txt' />
</reference>

      
      
<reference anchor='RFC5639'>
<front>
<title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation</title>
<author initials='M.' surname='Lochter' fullname='M. Lochter'>
<organization /></author>
<author initials='J.' surname='Merkle' fullname='J. Merkle'>
<organization /></author>
<date year='2010' month='March' />
</front>
<seriesInfo name='RFC' value='5639' />
<format type='TXT' octets='50566' target='http://www.rfc-editor.org/rfc/rfc5639.txt' />
</reference>


      

      <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>
        

    </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>        
        
      
<reference anchor='RFC5903'>

<front>
<title>Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE and IKEv2</title>
<author initials='D.' surname='Fu' fullname='D. Fu'>
<organization /></author>
<author initials='J.' surname='Solinas' fullname='J. Solinas'>
<organization /></author>
<date year='2010' month='June' />
</front>

<seriesInfo name='RFC' value='5903' />
<format type='TXT' octets='29175' target='http://www.rfc-editor.org/rfc/rfc5903.txt' />
</reference>
      

<reference anchor='RFC6090'>

<front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title>
<author initials='D.' surname='McGrew' fullname='D. McGrew'>
<organization /></author>
<author initials='K.' surname='Igoe' fullname='K. Igoe'>
<organization /></author>
<author initials='M.' surname='Salter' fullname='M. Salter'>
<organization /></author>
<date year='2011' month='February' />
<abstract>
<t>This note describes the fundamental algorithms of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 and earlier.  These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years.  Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B.  This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>

<seriesInfo name='RFC' value='6090' />
<format type='TXT' octets='75993' target='http://www.rfc-editor.org/rfc/rfc6090.txt' />
</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="Spec" /> .  In all
   of the following sections the following notation is used:
   <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 </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, y_Z are represented as hexadecimal values using the FieldElement-to-OctetString conversion method specified in <xref target='SEC1' />.
</t>

<section title="224 Bit Curve"> 

  <t>Curve brainpoolP224r1
   <list>
    <t>dA =   39F155483CEE191FBECFE9C81D8AB1A03CDA6790E7184ACE44BCA161 </t>

    <t>x_qA = A9C21A569759DA95E0387041184261440327AFE33141CA04B82DC92E </t>
    <t>y_qA = 98A0F75FBBF61D8E58AE5511B2BCDBE8E549B31E37069A2825F590C1 </t>

    <t>dB =   6060552303899E2140715816C45B57D9B42204FB6A5BF5BEAC10DB00 </t>

    <t>x_qB = 034A56C550FF88056144E6DD56070F54B0135976B5BF77827313F36B </t>
    <t>y_qB = 75165AD99347DC86CAAB1CBB579E198EAF88DC35F927B358AA683681 </t>

    <t>x_Z = 1A4BFE705445120C8E3E026699054104510D119757B74D5FE2462C66 </t>
    <t>y_Z =  BB6802AC01F8B7E91B1A1ACFB9830A95C079CEC48E52805DFD7D2AFE </t>
</list></t>

 
   </section>
<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>