Re: [TLS] [PATCH RFC4492bis] Add EdDSA signature support

[Yoav Nir <[e-mail]>]

LGTM. Can you push this to GitHub?

> On 20 Oct 2015, at 8:35 PM, Ilari Liusvaara <[e-mail]> wrote:
> 
> From: Ilari Liusvaara <[e-mail]>
> 
> ---
> On Tue, Oct 20, 2015 at 10:42:14AM +0300, Yoav Nir wrote:
>> Hi Ilari
>> 
>>> - Is this document meant to also include the CFRG signatures
>>> work? The interfaces to functions are already known.
>> 
>> That is the intention. A PR is welcome.
> 
> Well, here's an attempt at a patch. Comments welcome.
> 
> Idea is to use SignatureAndHash (eddsa, none) for EdDSA signatures,
> and have two new curves for it, one for Ed25519{,ph} and the other
> for Ed448{,ph}. I shared the ciphersuites and key exchange algorithms
> between ECDSA and EdDSA. Turned out to be bit cleaner than I expected
> in TLS 1.0/1.1 due to separate curves.
> 
> This also should incorporate the TLS 1.2 changes to signing algorithm
> requirements (but I may have missed some).
> 
> Also, the ECDH_fixed client signatures are still there. Should those be,
> those definitely destroy FPS and AFAIK aren't used in wild?
> 
> Also, the ciphersuite list looks bad. RC4... Really?
> 
> 
> draft-ietf-tls-rfc4492bis.xml | 154 ++++++++++++++++++++++++++++--------------
> 1 file changed, 103 insertions(+), 51 deletions(-)
> 
> diff --git a/draft-ietf-tls-rfc4492bis.xml b/draft-ietf-tls-rfc4492bis.xml
> index acf1525..0966bb8 100644
> --- a/draft-ietf-tls-rfc4492bis.xml
> +++ b/draft-ietf-tls-rfc4492bis.xml
> @@ -53,8 +53,8 @@
>     <abstract>
>       <t> This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport 
>         Layer Security (TLS) protocol.  In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman 
> -        (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) as 
> -        a new authentication mechanism.</t>
> +        (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and
> +        Edwards Digital Signature Algorithm (EdDSA) as new authentication mechanisms.</t>
>     </abstract>
>   </front>
>  <!-- 
> @@ -62,6 +62,8 @@
>   * Added mention of TLS 1.2
>   * Removed "required reading" for ECC from the Introduction. ECC is not longer "exotic"
>   * Moved the original authors to the Acknowledgement section.
> +  * Added EdDSA.
> +  * Added CFRG curves.
>   -->
>   <middle>
>     <!-- ====================================================================== -->
> @@ -119,7 +121,7 @@
>       <texttable anchor="tbl2" title="ECC Key Exchange Algorithms">
>         <ttcol align="left">Algorithm</ttcol>
>         <ttcol align="left">Description</ttcol>
> -        <c>ECDHE_ECDSA</c><c>Ephemeral ECDH with ECDSA signatures.</c>
> +        <c>ECDHE_ECDSA</c><c>Ephemeral ECDH with ECDSA or EdDSA signatures.</c>
>         <c>ECDHE_RSA</c><c>Ephemeral ECDH with RSA signatures.</c>
>         <c>ECDH_anon</c><c>Anonymous ephemeral ECDH, no signatures.</c>
>       </texttable>
> @@ -134,7 +136,7 @@
>       <t> Note that there is no structural difference between ECDH and ECDSA keys.  A certificate issuer may use 
>         X.509 v3 keyUsage and extendedKeyUsage extensions to restrict the use of an ECC public key to certain 
>         computations.  This document refers to an ECC key as ECDH-capable if its use in ECDH is permitted.  
> -        ECDSA-capable is defined similarly. <figure>
> +        ECDSA-capable and EdDSA-cabable are defined similarly. <figure>
>         <artwork><![CDATA[
>        Client                                        Server
>        ------                                        ------
> @@ -166,11 +168,10 @@
>         <xref target="clientauth" /> and of the optional ECC-specific extensions (which impact the Hello messages) 
>         until <xref target="tlsext" />.</t>
>       <section anchor="ecdhe_ecdsa" title="ECDHE_ECDSA">
> -        <t> In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable public key and be signed with 
> -          ECDSA.</t>
> +        <t> In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA-capable or EdDSA-capable public key.</t>
>         <t> The server sends its ephemeral ECDH public key and a specification of the corresponding curve in the 
> -          ServerKeyExchange message.  These parameters MUST be signed with ECDSA using the private key corresponding 
> -          to the public key in the server's Certificate.</t>
> +          ServerKeyExchange message.  These parameters MUST be signed with ECDSA or EdDSA using the private key
> +          corresponding to the public key in the server's Certificate.</t>
>         <t> The client generates an ECDH key pair on the same curve as the server's ephemeral ECDH key and sends its 
>           public key in the ClientKeyExchange message.</t>
>         <t> Both client and server perform an ECDH operation <xref target="alg_computes"/> and use the resultant 
> @@ -179,7 +180,7 @@
>       <section anchor="ecdhe_rsa" title="ECDHE_RSA">
>         <t> This key exchange algorithm is the same as ECDHE_ECDSA except that the server's certificate MUST contain 
>           an RSA public key authorized for signing, and that the signature in the ServerKeyExchange message must be 
> -          computed with the corresponding RSA private key.  The server certificate MUST be signed with RSA.</t>
> +          computed with the corresponding RSA private key.</t>
>       </section>
>       <section anchor="ecdh_anon" title="ECDH_anon">
>         <t> NOTE: Despite the name beginning with "ECDH_" (no E), the key used in ECDH_anon is ephemeral just like 
> @@ -193,14 +194,9 @@
>           its public key in the ClientKeyExchange message.</t>
>         <t> Both client and server perform an ECDH operation and use the resultant shared secret as the premaster 
>           secret.  All ECDH calculations are performed as specified in <xref target="alg_computes"/>.</t>
> -        <t> Note that while the ECDHE_ECDSA and ECDHE_RSA key exchange algorithms require the server's certificate 
> -          to be signed with a particular signature scheme, this specification (following the similar cases of 
> -          DHE_DSS, and DHE_RSA in the TLS base documents) does not impose restrictions on signature schemes used 
> -          elsewhere in the certificate chain.  (Often such restrictions will be useful, and it is expected that this 
> -          will be taken into account in certification authorities' signing practices.  However, such restrictions are 
> -          not strictly required in general: Even if it is beyond the capabilities of a client to completely validate 
> -          a given chain, the client may be able to validate the server's certificate by relying on a trusted 
> -          certification authority whose certificate appears as one of the intermediate certificates in the chain.)</t>
> +        <t> This specification does not impose restrictions on signature schemes used anywhere in the certificate chain.
> +          The previous version of this document required the signatures to match, but this restriction, originating
> +          in previous TLS versions is lifted here as it had been in RFC 5246.</t>
>       </section>
>     </section>
>     <section anchor="clientauth" title="Client Authentication">
> @@ -224,7 +220,7 @@
>         different type than the server certificate.</t>
>       <section anchor="ecdsa_sign" title="ECDSA_sign">
>         <t> To use this authentication mechanism, the client MUST possess a certificate containing an ECDSA-capable 
> -          public key and signed with ECDSA.</t>
> +          or EdDSA-capable public key.</t>
>         <t> The client proves possession of the private key corresponding to the certified key by including a 
>           signature in the CertificateVerify message as described in <xref target="cert_verify"/>.</t>
>       </section>
> @@ -291,9 +287,9 @@
>           cipher suites must be negotiated only if the server can successfully complete the handshake while using 
>           the curves and point formats supported by the client (cf. <xref target="server_cert"/> and 
>           <xref target="ske"/>).</t>
> -        <t> NOTE: A server participating in an ECDHE-ECDSA key exchange may use different curves for the ECDSA 
> -          key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message.  The server MUST 
> -          consider the extensions in both cases.</t>
> +        <t> NOTE: A server participating in an ECDHE_ECDSA key exchange may use different curves for the ECDSA or
> +          EdDSA key in its certificate, and for the ephemeral ECDH key in the ServerKeyExchange message.  The server
> +          MUST consider the extensions in both cases.</t>
>         <t> If a server does not understand the Supported Elliptic Curves Extension, does not understand the 
>           Supported Point Formats Extension, or is unable to complete the ECC handshake while restricting itself 
>           to the enumerated curves and point formats, it MUST NOT negotiate the use of an ECC cipher suite.  
> @@ -303,13 +299,15 @@
>           <t> RFC 4492 defined 25 different curves in the NamedCurve registry for use in TLS. Only three have seen 
>             any use. This specification is deprecating the rest (with numbers 1-22). This specification also 
>             deprecates the explicit curves with identifiers 0xFF01 and 0xFF02. It also adds the new curves 
> -            defined in <xref target="CFRG-Curves"/>. The end result is as follows:</t>
> +            defined in <xref target="CFRG-Curves"/> and <xref target="CFRG-EdDSA"/>. The end result is as follows:</t>
>           <figure><artwork><![CDATA[
>         enum {
>             deprecated(1..22),
>             secp256r1 (23), secp384r1 (24), secp521r1 (25),
>             Curve25519(TBD1),
>             Curve448(TBD2),
> +            Ed25519(TBD3),
> +            Ed448(TBD4),
>             reserved (0xFE00..0xFEFF),
>             deprecated(0xFF01..0xFF02),
>             (0xFFFF)
> @@ -320,7 +318,8 @@
>             curves.  The named curves secp256r1, secp384r1, and secp521r1 are specified in SEC 2 
>             <xref target="SECG-SEC2"/>. These curves are also recommended in ANSI X9.62 
>             <xref target="ANSI.X9-62.2005"/> and FIPS 186-4 <xref target="FIPS.186-4"/>. Curve25519 and Curve448 
> -            are defined in <xref target="CFRG-Curves"/>. Values 0xFE00 through 0xFEFF are reserved for private use.</t>
> +            are defined in <xref target="CFRG-Curves"/>. Ed25519 and Ed448 are signature-only curves defined in
> +            <xref target="CFRG-EdDSA"/>. Values 0xFE00 through 0xFEFF are reserved for private use.</t>
>           <t> The NamedCurve name space is maintained by IANA.  See <xref target="iana"/> for information on how new 
>             value assignments are added.</t>
>           <figure><artwork><![CDATA[
> @@ -349,7 +348,7 @@
> ]]></artwork></figure>
>           <t> Three point formats were included in the definition of ECPointFormat above. This specification 
>             deprecates all but the uncompressed point format. Implementations of this document MUST support the 
> -            uncompressed format for all of their supported curves, and MUST support no other formats for curves
> +            uncompressed format for all of their supported curves, and MUST NOT support other formats for curves
>             defined in this specification. For backwards compatibility purposes, the point format list extension
>             MUST still be included, and contain exactly one value: the uncomptessed point format (0).</t>
>           <t> The ECPointFormat name space is maintained by IANA.  See <xref target="iana"/> for information on how 
> @@ -449,7 +448,8 @@
>             represent an elliptic curve point in uncompressed or compressed format; it MUST conform to what the 
>             client has requested through a Supported Point Formats Extension if this extension was used. For the
>             Curve25519 and Curve448 curves, the only valid representation is the one specified in 
> -            <xref target="CFRG-Curves"/> - a 32- or 56-octet representation of the u value of the point.</t>
> +            <xref target="CFRG-Curves"/> - a 32- or 56-octet representation of the u value of the point. This structure
> +            MUST NOT be used with Ed25519 and Ed448 public keys.</t>
>           <t> <figure><artwork><![CDATA[
>         struct {
>             ECCurveType    curve_type;
> @@ -462,9 +462,9 @@
>           <t hangText="curve_type:"> This identifies the type of the elliptic curve domain parameters.</t>
>           <t hangText="namedcurve:"> Specifies a recommended set of elliptic curve domain parameters.  All those 
>             values of NamedCurve are allowed that refer to a specific curve.  Values of NamedCurve that indicate 
> -            support for a class of explicitly defined curves are not allowed here (they are only permissible in 
> -            the ClientHello extension); this applies to arbitrary_explicit_prime_curves(0xFF01) and 
> -            arbitrary_explicit_char2_curves(0xFF02).</t>
> +            support for a class of explicitly defined curves or signature-only curves are not allowed here (they are
> +            only permissible in the ClientHello extension); this applies to Ed25519(TBD3), Ed448(TBD4),
> +            arbitrary_explicit_prime_curves(0xFF01) and arbitrary_explicit_char2_curves(0xFF02).</t>
>           <t><figure><artwork><![CDATA[
>         struct {
>             ECParameters    curve_params;
> @@ -488,20 +488,27 @@
>           <t hangText="signed_params:"> A hash of the params, with the signature appropriate to that hash applied.  
>             The private key corresponding to the certified public key in the server's Certificate message is used 
>             for signing.<figure><artwork><![CDATA[
> -     enum { ecdsa } SignatureAlgorithm;
> +     enum { ecdsa(3), eddsa(TBD5) } SignatureAlgorithm;
>      select (SignatureAlgorithm) {
>         case ecdsa:
>              digitally-signed struct {
>                  opaque sha_hash[sha_size];
>              };
> +        case eddsa:
> +             digitally-signed struct {
> +                 opaque rawdata[rawdata_size];
> +             };
>      } Signature;
>    ServerKeyExchange.signed_params.sha_hash
>        SHA(ClientHello.random + ServerHello.random +
>                               ServerKeyExchange.params);
> +   ServerKeyExchange.signed_params.rawdata
> +       ClientHello.random + ServerHello.random +
> +                              ServerKeyExchange.params;
> ]]></artwork></figure></t></list></t>
>         <t> NOTE: SignatureAlgorithm is "rsa" for the ECDHE_RSA key exchange algorithm and "anonymous" for ECDH_anon.  
> -          These cases are defined in TLS.  SignatureAlgorithm is "ecdsa" for ECDHE_ECDSA.  ECDSA signatures are 
> -          generated and verified as described in <xref target="alg_computes"/>, and SHA in the above template for 
> +          These cases are defined in TLS.  SignatureAlgorithm is "ecdsa" or "eddsa" for ECDHE_ECDSA.  ECDSA signatures
> +          are generated and verified as described in <xref target="alg_computes"/>, and SHA in the above template for
>           sha_hash accordingly may denote a hash algorithm other than SHA-1.  As per ANSI X9.62, an ECDSA signature 
>           consists of a pair of integers, r and s.  The digitally-signed element is encoded as an opaque vector 
>           &lt;0..2^16-1&gt;, the contents of which are the DER encoding corresponding to the following ASN.1 
> @@ -511,6 +518,9 @@
>                s       INTEGER
>            }
> ]]></artwork></figure></t>
> +        <t>EdDSA signatures are generated and verified according to <xref target="CFRG-EdDSA"/>. The digitally-signed
> +          element is encoded as an opaque vector&lt;0..2^16-1&gt;, the contents of which is the octet string output of
> +          the EdDSA signing algorithm.</t>
>         <t> Actions of the sender:</t>
>         <t> The server selects elliptic curve domain parameters and an ephemeral ECDH public key corresponding to 
>           these parameters according to the ECKAS-DH1 scheme from IEEE 1363 <xref target="IEEE.P1363.1998"/>.  
> @@ -558,14 +568,14 @@
>           certificates as described in <xref target="eccerts"/>.</t>
>         <t> NOTE: The client's Certificate message is capable of carrying a chain of certificates.  The 
>           restrictions mentioned in Table 4 apply only to the client's certificate (first in the chain).</t>
> -    	<texttable anchor="tbl4" title="Client Certificate Types">
> +        <texttable anchor="tbl4" title="Client Certificate Types">
>           <ttcol align="left">Client Authentication Method</ttcol>
>           <ttcol align="left">Client Certificate Type</ttcol>
> -          <c>ECDSA_sign</c><c>Certificate MUST contain an ECDSA-capable public key and be signed with ECDSA.</c>
> +          <c>ECDSA_sign</c><c>Certificate MUST contain an ECDSA-capable or EdDSA-capable public key.</c>
>           <c>ECDSA_fixed_ECDH</c><c>Certificate MUST contain an ECDH-capable public key on the same elliptic curve 
> -            as the server's long-term ECDH key.  This certificate MUST be signed with ECDSA.</c>
> -          <c>RSA_fixed_ECDH</c><c>Certificate MUST contain an ECDH-capable public key on the same elliptic curve 
> -            as the server's long-term ECDH key.  This certificate MUST be signed with RSA.</c>
> +            as the server's long-term ECDH key.</c>
> +          <c>RSA_fixed_ECDH</c><c>The same as ECDSA_fixed_ECDH. The codepoints meant different things, but due to
> +            changes in TLS 1.2, both mean the same thing now.</c>
>       </texttable>
>       <t> Structure of this message:</t>
>       <t> Identical to the TLS client Certificate format.</t>
> @@ -599,9 +609,10 @@
>         } ClientECDiffieHellmanPublic;
> ]]></artwork></figure></t>
>           <t hangText="ecdh_Yc:"> Contains the client's ephemeral ECDH public key as a byte string ECPoint.point, 
> -            which may represent an elliptic curve point in uncompressed or compressed format.  Here, the format 
> -            MUST conform to what the server has requested through a Supported Point Formats Extension if this 
> -            extension was used, and MUST be uncompressed if this extension was not used.<figure><artwork><![CDATA[
> +            which may represent an elliptic curve point in uncompressed or compressed format. Curves Ed25519 and
> +            Ed448 MUST NOT be used. Here, the format MUST conform to what the server has requested through a Supported
> +            Point Formats Extension if this extension was used, and MUST be uncompressed if this extension was not
> +            used.<figure><artwork><![CDATA[
>         struct {
>             select (KeyExchangeAlgorithm) {
>                 case ec_diffie_hellman: ClientECDiffieHellmanPublic;
> @@ -625,11 +636,14 @@
>           key in the client's Certificate message.</t>
>         <t> Structure of this message:</t>
>         <t> The TLS CertificateVerify message and the underlying Signature type are defined in the TLS base 
> -          specifications, and the latter is extended here in <xref target="ske"/>.  For the ecdsa case, the signature 
> -          field in the CertificateVerify message contains an ECDSA signature computed over handshake messages 
> -          exchanged so far, exactly similar to CertificateVerify with other signing algorithms:<figure><artwork><![CDATA[
> +          specifications, and the latter is extended here in <xref target="ske"/>.  For the ecdsa and eddsa cases, the
> +          signature field in the CertificateVerify message contains an ECDSA or EdDSA (respectively) signature computed
> +          over handshake messages exchanged so far, exactly similar to CertificateVerify with other signing
> +          algorithms:<figure><artwork><![CDATA[
>         CertificateVerify.signature.sha_hash
>             SHA(handshake_messages);
> +        CertificateVerify.signature.rawdata
> +            handshake_messages;
> ]]></artwork></figure></t>
>         <t> ECDSA signatures are computed as described in <xref target="alg_computes"/>, and SHA in the above 
>           template for sha_hash accordingly may denote a hash algorithm other than SHA-1.  As per ANSI X9.62, an 
> @@ -641,6 +655,9 @@
>             s       INTEGER
>         }
> ]]></artwork></figure></t>
> +        <t>EdDSA signatures are generated and verified according to <xref target="CFRG-EdDSA"/>. The digitally-signed
> +          element is encoded as an opaque vector&lt;0..2^16-1&gt;, the contents of which is the octet string output of
> +          the EdDSA signing algorithm.</t>
>         <t> Actions of the sender:</t>
>         <t> The client computes its signature over all handshake messages sent or received starting at client hello 
>           and up to but not including this message.  It uses the private key corresponding to its certified public 
> @@ -651,8 +668,12 @@
>       </section>
>       <section anchor="eccerts" title="Elliptic Curve Certificates">
>         <t> X.509 certificates containing ECC public keys or signed using ECDSA MUST comply with 
> -          <xref target="RFC3279"/> or another RFC that replaces or extends it. Clients SHOULD use the elliptic 
> -          curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2 <xref target="SECG-SEC2"/>.</t>
> +          <xref target="RFC3279"/> or another RFC that replaces or extends it. X.509 certificates containing ECC
> +          public keys or signed using EdDSA MUST comply with <xref target="PKIX-EdDSA"/>. Clients SHOULD use the
> +          elliptic curve domain parameters recommended in ANSI X9.62, FIPS 186-4, and SEC 2
> +          <xref target="SECG-SEC2"/> or in <xref target="CFRG-EdDSA"/>.</t>
> +        <t>EdDSA keys using Ed25519 and Ed25519ph algorithms MUST use the Ed25519 curve, and Ed448 and Ed448ph keys
> +          MUST use the Ed448 curve. Curves Curve25519, Curve448, Ed25519 and Ed448 MUST NOT be used for ECDSA.</t>
>       </section>
>       <section anchor="alg_computes" title="ECDH, ECDSA, and RSA Computations">
>         <t> All ECDH calculations for the NIST curves (including parameter and key generation as well as the shared 
> @@ -675,11 +696,15 @@
>           signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional 
>           hashing.  The default hash function is SHA-1 <xref target="FIPS.180-2"/>, and sha_size (see 
>           <xref target="ske"/> and <xref target="cert_verify"/>) is 20. However, an alternative hash function, such 
> -          as one of the new SHA hash functions specified in FIPS 180-2 <xref target="FIPS.180-2"/>, may be used instead.</t>
> +          as one of the new SHA hash functions specified in FIPS 180-2 <xref target="FIPS.180-2"/>, SHOULD be used instead.</t>
> +        <t> All EdDSA computations MUST be performed according to <xref target="CFRG-EdDSA"/> or its succesors. Data
> +          to be signed/verified is run through the EdDSA algorithm wih no hashing (EdDSA will internally run the data
> +          through the PH function).</t>
>         <t> RFC 4492 anticipated the standardization of a mechanism for specifying the required hash function in the certificate,
>         perhaps in the parameters field of the subjectPublicKeyInfo. Such standardization never took place, and as a result, 
> -        SHA-1 is used in TLS 1.1 and earlier. TLS 1.2 added a SignatureAndHashAlgorithm parameter to the DigitallySigned struct, 
> -        thus allowing agility in choosing the signature hash.</t>
> +        SHA-1 is used in TLS 1.1 and earlier (except for EdDSA, which uses identity function). TLS 1.2 added a
> +        SignatureAndHashAlgorithm parameter to the DigitallySigned struct, thus allowing agility in choosing the
> +        signature hash. EdDSA signatures MUST have HashAlgorithm of 0 (None).</t>
>         <t> All RSA signatures must be generated and verified according to <xref target="PKCS1"/> block type 1.</t>
>       </section>
>       <section anchor="valid25519" title="Public Key Validation">
> @@ -688,14 +713,16 @@
>           key, to the point that they may recover the entire private key in a few requests, if that key is not really
>           ephemeral.</t>
>         <t> Curve25519 was designed in a way that the result of Curve25519(x, d) will never reveal information about 
> -          d, provided it was chosen as prescribed, for any value of x.</t>
> +          d, provided it was chosen as prescribed, for any value of x (the same holds true for Curve448).</t>
>         <t> Let's define legitimate values of x as the values that can be obtained as x = Curve25519(G, d') for some 
>           d, and call the other values illegitimate.  The definition of the Curve25519 function shows that legitimate 
> -          values all share the following property: the high-order bit of the last byte is not set.</t>
> +          values all share the following property: the high-order bit of the last byte is not set (for Ed448, any bit
> +          can be set).</t>
>         <t> Since there are some implementation of the Curve25519 function that impose this restriction on their input 
>           and others that don't, implementations of Curve25519 in TLS SHOULD reject public keys when the high-order bit 
>           of the last byte is set (in other words, when the value of the leftmost byte is greater than 0x7F) in order 
>           to prevent implementation fingerprinting.</t>
> +        <t>Ed25519 and Ed448 internally do public key validation as part of signature verification.</t>
>         <t> Other than this recommended check, implementations do not need to ensure that the public keys they receive 
>           are legitimate: this is not necessary for security with Curve25519.</t>
>       </section>
> @@ -770,8 +797,10 @@
>       <t> NOTE: IANA, please update the registries to reflect the new policy name.</t>
>       <t> NOTE: RFC editor please delete these two notes prior to publication.</t>
>       <t> IANA, please update these two registries to refer to this document.</t>
> -      <t> IANA is requested to assign two values from the NamedCurve registry with names Curve25519(TBD1) and
> -        Curve448(TBD2) with this document as reference.</t>
> +      <t> IANA is requested to assign four values from the NamedCurve registry with names Curve25519(TBD1),
> +        Curve448(TBD2), Ed25519(TBD3) and Ed448(TBD4) with this document as reference.</t>
> +      <t> IANA is requested to assign one value from SignatureAlgorithm Registry with name eddsa(TBD5) with this
> +        document as reference.</t>
>     </section>
>     <section anchor="ack" title="Acknowledgements">
>       <t> Most of the text is this document is taken from <xref target="RFC4492"/>, the predecessor of this 
> @@ -785,6 +814,9 @@
>     </section>
>     <section anchor="history" title="Version History for This Draft">
>       <t> NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION</t>
> +      <t> Changes from draft-ietf-tls-rfc4492bis-03 to draft-nir-tls-rfc4492bis-05:<list style="symbols">
> +        <t> Add support for CFRG curves and signatures work.</t>
> +        </list></t>
>       <t> Changes from draft-ietf-tls-rfc4492bis-01 to draft-nir-tls-rfc4492bis-03:<list style="symbols">
>         <t> Removed unused curves.</t>
>         <t> Removed unused point formats (all but uncompressed)</t>
> @@ -816,6 +848,26 @@
>         <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-curves-11"/>
>         <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-cfrg-curves-11.txt"/>
>       </reference>
> +      <reference anchor="CFRG-EdDSA">
> +        <front>
> +          <title>EdDSA: Ed25519 and Ed448</title>
> +            <author initials="S" surname="Josefsson" fullname="Simon Josefsson"></author>
> +            <author initials="I" surname="Liusvaara" fullname="Ilari Liusvaara"></author>
> +            <date month="October" day="8" year="2015"/>
> +          </front>
> +        <seriesInfo name="Internet-Draft" value="draft-irtf-cfrg-eddsa-00"/>
> +        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-irtf-cfrg-eddsa-00.txt"/>
> +      </reference>
> +      <reference anchor="PKIX-EdDSA">
> +        <front>
> +          <title>Using EdDSA in the Internet X.509 Public Key Infrastructure</title>
> +            <author initials="S" surname="Josefsson" fullname="Simon Josefsson"></author>
> +            <author initials="N" surname="Mavrogiannopoulos" fullname="Nikos Mavrogiannopoulos"></author>
> +            <date month="September" day="23" year="2015"/>
> +          </front>
> +        <seriesInfo name="Internet-Draft" value="draft-josefsson-pkix-eddsa-03"/>
> +        <format type="TXT" target="http://www.ietf.org/internet-drafts/draft-josefsson-pkix-eddsa-03"/>
> +      </reference>
>       <reference anchor='RFC2246'>
>         <front>
>           <title>The TLS Protocol Version 1.0</title>
> -- 
> 2.6.1
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls