Subject: [Curdle] Proposal: Disallow Ed25519ph/Ed448ph for CA certificates

From: Brian Smith <[email-masked]>
Date: Tue, 7 Jun 2016 12:05:49 -1000

I proposal that the spec be updated to say that certificates with
basicConstraints.cA = TRUE MUST NOT use Ed25519ph or Ed448ph public keys.

The non-prehash variants are more misuse-resistant than the prehash
variants, which is a particularly important property for CA certificates.

More generally, in practice it seems likely that Ed25519 (non-prehash) will
be much more ubiquitous than the prehash variants, as the non-prehash
variants are already being used in (non-IETF) protocols that are deployed.
I have seen very little support for the prehash variants, and also very
little need to support for prehash variants. So, for example, my
implementation doesn't support the prehash variants at all.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: David Benjamin <[email-masked]>
Date: Wed, 08 Jun 2016 20:55:50 +0000

I think this is a good idea. No need to add unnecessary knobs for modes
that won't (or shouldn't) be used. It would be a shame if we ended up in a
world where everyone had to implement the pre-hash algorithms because half
of certs used Ed25519ph and half used Ed25519.

(In comparison, TLS 1.3 does not currently define a use for them and only
uses PureEdDSA.)

We could just not bother defining X.509 signature mappings for Ed25519ph
and Ed448ph, but it'd be good to explicitly call out that Ed{25519,448}ph +
basicConstraints.cA = TRUE is not okay. (Especially if we just use the same
OIDs for SPKI and signature algorithms, folks might interpolate.)

David

On Tue, Jun 7, 2016 at 6:05 PM Brian Smith <[email-masked]> wrote:

> More generally, in practice it seems likely that Ed25519 (non-prehash)
> will be much more ubiquitous than the prehash variants, as the non-prehash
> _______________________________________________
> Curdle mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 10 Jun 2016 05:18:40 -0400 (EDT)

Don't underestimate the value of the prehash variant. How would you hash
a 1GB file using an 8-bit smart card? Today you simply pass the hash and
get back and RSA or ECDSA signature, but with the ed25519 plain variant
you have to pipe the whole file through the card.

I'm not really happy with the variants available as we end up with
situations where two implementations will implement the draft and still be
incompatible between them (in fact your implementation will be incompatible
with mine as I've gone for the prehashed variants only).

regards,
Nikos

----- Original Message -----

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 10 Jun 2016 10:26:12 -0400

> you have to pipe the whole file through the card.

This proposal was just for CA certificates, though.  What CA needs to
sign a 1GB file?

     --dkg

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 13 Jun 2016 04:02:42 -0400 (EDT)

I believe my answer was targeted to the second part of the mail which
mentioned that Brian's implementation will not support the ed25519ph
variant. 

About the first part if I can add is that it is indifferent to
me whether this restriction is added or not. The CAs that require that
kind of security can always use that algorithm even if IETF doesn't
mandate it. On the other hand I don't like this type of restrictions
because they only complicate things (if for example I have an application
which handles only ed25519ph why should I not be able to use it to make
a local CA?)

regards,
Nikos

----- Original Message -----

     --dkg

---

From: Martin Thomson <[email-masked]>
Date: Tue, 14 Jun 2016 07:48:24 +0100

On 13 June 2016 at 09:02, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> (if for example I have an application

That's an easy question to answer.  Ask the same question with a
completely different signature algorithm.  For instance, DSA.  If you
choose to implement an algorithm that isn't used by other people, you
lose.  There is a distinct benefit to having a very narrow set of
signature algorithms supported by the PKI.  In this case, ed25519
(pure) is the right choice for all the aforementioned reasons.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 14 Jun 2016 04:10:04 -0400 (EDT)

If you believe so then push for making that the only option rather than creating
a complex situation for everyone.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Jun 2016 10:45:36 +0000

Hi Martin,

EdDsa is the most recommended signature algorithm by SAAG/IETF now. This
signature algorithm will be much used in the future until practical
quantum computers become available. This period of time could be 10, 20 or
more years.

I believe we are in an early stage of using EdDSA and pureEdDSA is not
widely used yet. In addition, I believe that adding support for Eddsa_ph
is not too costly because the hash function is already available in the
code for pureEddsa already.

One signature algorithm works well for all uses would be a win win for the
IETF and everyone else in the security world.

Regards,
Quynh.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Jun 2016 17:25:02 +0300

> code for pureEddsa already.

Eeh... I thought almost all use of EdDSA was Ed25519 (with possibly
ad-hoc prehashing depending on application), and use of Ed25519ph is
almost nonexistent.

Also, remember that use of the same key as Ed25519 and Ed25519ph
key must not be allowed (due to well-known problems).

-Ilari

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Jun 2016 15:21:14 +0000

On 6/14/16, 10:25 AM, "[email-masked] on behalf of Ilari

>ad-hoc prehashing depending on application), and use of Ed25519ph is

The points were that 1) I believe the use of Ed25519 is still not large
yet and 2) It would be great to use one algorithm which works well for all
uses for a long time in the future.

>key must not be allowed (due to well-known problems).

I Never recommended using the same key for both.

Regards,
Quynh.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 14 Jun 2016 18:40:11 +0300

> uses for a long time in the future.

My recommendation regarding Ed25519ph and Ed448ph: Do not use.

Basically, if you have an application where Ed25519 is bad fit, Ed25519ph
is going to fit it pretty badly too (and the right way would be to do
application-specific preprocessing before signing). And similarly for
Ed448/Ed448ph.

-Ilari

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 14 Jun 2016 16:48:20 +0000

On 6/14/16, 11:40 AM, "[email-masked] on behalf of Ilari

>My recommendation regarding Ed25519ph and Ed448ph: Do not use.

Why?

>is going to fit it pretty badly too

Not true. If you need to sign big messages, prehash helps here.

> (and the right way would be to do
>application-specific preprocessing before signing).

Prehash? Or something else?

>And similarly for

Every where, an Eddsa works well, then the Eddsa_prehash version also
works well, but not the other way around.

>-Ilari

It would be best if one signature algorithm is used in all protocols
instead of 2. I believe the use of ed25519 is still not big and adding
support for the prehash is not too costly.

Quynh.