Subject: [TLS] Fwd: Updated elliptic curve drafts

From: Simon Josefsson <[email-masked]>
Date: Mon, 12 Oct 2015 22:47:58 +0200

FYI -- posted to [email-masked].  Intended to work together with
draft-josefsson-tls-eddsa or draft-josefsson-tls-eddsa2.

/Simon

From: Simon Josefsson <[email-masked]>
Subject: Updated elliptic curve drafts
To: [email-masked]
Date: Mon, 12 Oct 2015 22:25:31 +0200

Hi,

I've updated my drafts on Curve25519/Curve448 support in PKIX to refer
to the CFRG-Curves and CFRG-EdDSA drafts.

The following document adds new EdDSA key/signature OIDs directly:

https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

The following document adds new namedCurve OIDs, thus going indirectly
through the existing ECDSA 3279 route:

https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

These two drafts take different approaches to including the new curves
into PKIX, and currently both lack applicability statements.  There is
potential for overlap and conflict right now.  It recently came up that
for PKCS#11 a namedCurve approach would be useful, but for normal PKIX
Certificates, it may be that the first direct approach is preferrable.
The former lack the possibility of encoding keys for DH.  I believe each
approach can be useful on its own, but we need to include text adressing
use-cases that can be resolved by both documents to avoid conflicts.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 13 Oct 2015 08:23:29 +0300

> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-04

The certificate example seems to contain OID 1.3.101.100.1... Is that
intended or should it be 1.3.101.101?

IIRC, someone pointed mistake in OIDs before, dunno if that has been
corrected.
 
> https://tools.ietf.org/html/draft-josefsson-pkix-newcurves-01

I think this approach is unsuitable for signature keys, but it would
be suitable for X25519/X448 DH public keys, which some people apparently
have been requesting (IiRC, I have heard requests for that, don't
remember from whom)..

And AFAICT, those keys don't have associated hashes, and such public keys
should be marked for DH only (1.3.132.1.12).

> use-cases that can be resolved by both documents to avoid conflicts.

IMO, new algorithm is more suited for signature keys, whereas new curve
is more suited for DH public keys.

This is because there is currently no way to designate correct algorithm
for signatures[1], whereas there is for DH, so one just needs to
designate correct curve.

[1] ECDSA uses "unrestricted", which has been implicated in TLS ECDH
KCI MITM attack (equivalent attack doesn't work for "discrete" DH because
signature keys are distinct from DH keys).

-Ilari