From: Ilari Liusvaara <ilariliusva...@welho.com>
---
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
<0..2^16-1>, 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<0..2^16-1>, 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<0..2^16-1>, 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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
