Re: [TLS] Additional Elliptic Curves (Curve25519 etc) for TLS ECDH key agreement

[Manuel Pégourié-Gonnard <[e-mail]>]

On 11/01/2014 18:28, Dr Stephen Henson wrote:
> On 11/01/2014 16:32, Simon Josefsson wrote:
>>
>> 2) Does description of private/public key representation and computation
>>    of shared secret belong in draft-josefsson-tls-curve25519?  It has to
>>    be somewhere, I believ, but possibly this could go into
>>    draft-ladd-safecurves, or some other generic document, unless there
>>    are TLS-specific aspects.  Insight into this would be appreciated.
>>
> 
> A comment on the following paragraph:
> 
>    This document only describes usage of additional curves for ephemeral
>    key exchange (ECDHE), not for use with long-term keys embedded in
>    PKIX certificates (ECDH_ECDSA and ECDH_ECDSA).  This is because
>    Curve25519 is not directly suitable for authentication with ECDSA,
>    and thus not applicable for signing of e.g.  PKIX certificates.  See
>    draft-josefsson-eddsa-ed25519 for a parallel effort.
> 
> Although the curves are not directly suitable for authentication this doesn't
> actually matter because the certificate doesn't have to be signed using the same
> curve or indeed the same algorithm. So it would (for example) permit a
> certificate containing a curve25519 key signed by a CA using a Brainpool curve
> (or even RSA with the relaxed CA signing rules of TLS 1.2). However to do that
> would require a standard for the use of curve25519 in certificates which
> currently doesn't exist.
> 
Agreed. Actually, a previous (unpublished) version of the draft had a more
precise wording about that, but I unfortunately deleted it in the editing
process. Thanks for noticing.

> Having said that the static ECDH ciphersuites are rarely used and don't offer
> forward secrecy.
> 
Right.

> IMHO a discussion of private/public key format should be in a separate document
> which would include an appropriate ASN1.1 format (e.g. PKCS#8 for private keys
> and SubjectPublicKeyInfo for public keys). That would enable the use of
> curve25519 (and other curves) in a wider range of applications, not just TLS.
> 
I don't disagree that such a document would be a useful addition, but since
ECDHE in TLS isn't using ASN.1 to represent the keys, and only needs to
represent public keys, I felt like the easiest way forward was to specify only
what's needed to do ECDHE in TLS, that is how to represent public keys, without
ASN.1.

Manuel.