<?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-01" 
   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="2012" />


    <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 RFC 5639 <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='RFC4306' /> requires the definition and assignment of additional transform IDs in the respective IANA registry. This document specifies tranform IDs for four curves from RFC 5639. Furthermore, the encoding of the key exchange payload and derivation of the shared secret are defined, because previous RFCs specified this encoding only for the curves proposed therein.</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="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>TBD1</c>
  <c>brainpoolP256r1</c>
  <c>TBD2</c>
  <c>brainpoolP384r1</c>
  <c>TBD3</c>
  <c>brainpoolP512r1</c>
  <c>TBD4</c>
<postamble></postamble>
</texttable>

<t>The corresponding "twisted curves" defined in RFC 5639 can be used by implementations without having separate transform IDs defined: points (x,y) of any curve listed in <xref target='transformIDs' /> 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 RFC 5639.</t>

<t>Test vectors for the groups defined by the ECC Brainpool curves are provided in <xref target='test_vectors' /></t>
 </section>
 
        <section anchor="encoding" title="Key Exchange Payload and Shared Secret">
          
         <t>RFC4306 <xref target='RFC4306' /> only specifies the use of MODP groups and GF[2^N] elliptic curve groups for Diffie-Hellman key exchange with IKEv2. For Diffie-Hellman groups of elliptic curves defined over prime fields (ECP Diffie-Hellman groups), however, the format of key
   exchange payloads and the derivation of a shared secret has  thus far not been specified generally but 
   on a group-by-group basis. To accomodate for different bandwidth limitations, for the groups defined in this document, two different methods for encoding the key exchange payload, compressed and uncompressed,  are specified. </t>

    <t>In an ECP key exchange, 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>

     <texttable anchor='bitlengths'>
  <preamble></preamble>
  <ttcol align='center'>Curves</ttcol>
  <ttcol align='center'>Bit lengths</ttcol>
   <c>brainpoolP224r1</c>
  <c>224</c>
  <c>brainpoolP256r1</c>
  <c>256</c>  
  <c>brainpoolP384r1</c>
  <c>384</c>  
  <c>brainpoolP512r1</c>
  <c>512</c> 
<postamble></postamble>
</texttable>
   
  
   <t>From these components, the key exchange payload MUST be computed using one of the two following encodings.

    <list style='numbers'>
   <t>Uncompressed. This method equals the method specified in RFC 5903 <xref target='RFC5903' /> for the ECP curves proposed therein. The key exchange payload is defined as the concatenation of the x and y coordinates. Using this method, the bit length of the key exchange payload is twice the bit length of each component listed in <xref target='bitlengths' />. If a peer receives a key exchange payload for an ECC Brainpool curve having twice the bitlength indicated for that curve in <xref target='bitlengths' />, it MUST assume that the uncompressed encoding has been used.</t>
   <t>Compressed. The key exchange payload is defined as x. Using this method, the bit length of the key exchange payload equals the bit length of each component listed in <xref target='bitlengths' />. If a peer receives a key exchange payload for an ECC Brainpool curve having the bitlength indicated for that curve in <xref target='bitlengths' />, it MUST assume that the compressed encoding has been used.</t>
   </list></t>
   
      
    <t>The Diffie-Hellman 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' />. The parties MUST verify that the Diffie-Hellman common value is not the "point at infinity", i.e. that the shared secret derived contains non-zero octets.</t>
   
  <t>When compressed encoding is used, computation of the Diffie-Hellman common value, and hence, of the shared secret value from the x-coordinate transmitted in the key exchange payload requires recovery of a correspoding y-coordinate. Since there are up to two possible points on the elliptic curve having a given x-coordinate, the recovered y-component is not unique. However, as explained in <xref target='RFC6090' />, any of the two y-coordinates corresponding to the x-value transmitted in the key exchange payload can be used to compute the Diffie-Hellman common value.</t>
   
   </section>
   </section>


   <section anchor="Security" title="Security Considerations">
   
   <t>The security considerations of <xref target="RFC4306"/> apply accordingly.</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 may 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 may 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> Before this document can become an RFC, IANA is required to update the Transform Type 4 (Diffie-Hellman Group Transform) IDs in its Internet Key Exchange Version 2 (IKEv2) Parameters registry <xref target='IANA-IKE2' />. In particular, numbers are to be assigned to the groups specified in <xref target='transformIDs' />. Another I-D is being submitted for publication as RFC <xref target='BP_IKE' /> requesting assignment for the same groups in the corresponding registry for IKEv1; in order to keep the registries for IKEv1 and IKEv2 in accordance, it is advisable to assign the same values in both registries.</t>
  </section>

    
   <section title="Intellectual Property Rights">

   <t>Although, the authors have no knowledge about any intellectual property rights
   which cover the general usage of the ECP groups defined herein, implementations based on these
   domain parameters may require use of inventions covered by patent rights. In particular, the compressed encoding method for the key exchange payload defined in <xref target="encoding"/> and techniques for an efficient arithmetic based on the special parameters of the twisted curves as explained in <xref target="IDs"/> may be covered by patents.</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='RFC4306'>

<front>
<title>Internet Key Exchange (IKEv2) Protocol</title>
<author initials='C.' surname='Kaufman' fullname='C. Kaufman'>
<organization /></author>
<date year='2005' month='December' />
</front>

<seriesInfo name='RFC' value='4306' />
<format type='TXT' octets='250941' target='http://www.rfc-editor.org/rfc/rfc4306.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>


      

    </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 für 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="BP_IKE">
      <front>
      <title>Brainpool Elliptic Curves for the IKE Group Description Registry</title>
      <author initials='D.' surname='Harkins' fullname='Dan Harkins'><organization /></author>
      <date month="August" year="2012" />
      </front>
       <seriesInfo name='Internet-Draft' value='draft-harkins-brainpool-ike-groups-00' />
      </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="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="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>