Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS

From: Rick Andrews <[email-masked]>
Date: Tue, 23 Jun 2015 04:41:48 -0700

Symantec owns Thawte which owns 1.3.101. We're happy to donate a reasonable
number of OIDs under this arc for your purposes. Please let me know if you'd
like to take us up on the offer. Thanks to Rob Stradling for bringing this
to my attention.

-Rick

-----Original Message-----
Date: Thu, 21 May 2015 19:42:53 -0700
From: Peter Bowen <[email-masked]>
To: Nico Williams <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, "[email-masked]"
	<[email-masked]>
Subject: Re: [TLS] Strawman on EdDSA/Ed25519 in TLS
Message-ID:
	<CAK6vND8uKT9AamW6d43CM3FipGqkCnp6x0=[email-masked]>
Content-Type: text/plain; charset=UTF-8

On Wed, May 20, 2015 at 12:07 PM, Nico Williams <[email-masked]>
wrote:
> On Wed, May 20, 2015 at 07:14:47PM +0200, Simon Josefsson wrote:
>> Support for EdDSA/Ed25519 in TLS has been suggested a couple of times.
>
> I'm in favor.
>
>> One aspect I'm aware of is that there is no OID allocated nor 
>> specification of PKIX certificates with EdDSA/Ed25519 public keys.  
>> I'm not sure the above document is the right place for doing that 
>> though, and more thinking around this topic is especially appreciated.
>
> It's an OID.  You can get your own OID arc and then allocate an OID.
>
> Is it important to separate the addition of a PKIX algorithm OID from 
> the TLS bits?  Well, it is neater that way.

I'll donate a short OID to the cause if that will help move things forward.
We have the 1.3.187 arc which is only three bytes DER.  If someone has a
smaller arc (third node would be 127 or lower) and would offer an OID from
their arc we can shave off another couple of bytes.

---

From: Simon Josefsson <[email-masked]>
Date: Sat, 27 Jun 2015 20:04:50 +0200

Hi Rick -- thank you for the offer!  Would you please allocate a range
of OIDs for EdDSA-based signatures?  I suggest:

1.3.101.1     EdDSA Ed25519 PKIX public keys
1.3.101.2     EdDSA Ed25519 PKIX signatures
1.3.101.3     EdDSA Ed448 PKIX public keys
1.3.101.4     EdDSA Ed448 PKIX signatures
1.3.101.5     EdDSA Curve41417 PKIX public keys
1.3.101.6     EdDSA Curve41417 PKIX signatures
1.3.101.7-16  <<Reserved for EdDSA with other TBD curves>>

I can update draft-josefsson-pkix-eddsa-01 once you confirm.

If you don't want to start at .1 for historic or other reasons, we can
start at a higher number.  But please keep the number low so it won't
increase the DER encoded size of the OID.

Btw, there is still some possibility of reaching even shorter OID size
by allocating from the 0.0-0.39 range, as suggested by Rob Stradling.  I
think we are approaching the point of diminishing returns now though.

/Simon

Rick Andrews <[email-masked]> writes:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 27 Jun 2015 21:13:05 +0300

> 1.3.101.7-16  <<Reserved for EdDSA with other TBD curves>>

AFAIK, Ed448 and Curve41417 do not meet defintion of curve by EdDSA.

And what hash would those use (I presume Ed25519 would use SHA-512)?

-Ilari

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 29 Jun 2015 10:06:48 +0200

> And what hash would those use (I presume Ed25519 would use SHA-512)?

I believe details for EdDSA with other curves will be available shortly,
and allocating an OID now will save us some time.

/Simon

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 29 Jun 2015 11:42:12 +0300

> and allocating an OID now will save us some time.

Well, I think that defining serialization of points + basepoints[1] for
Curve41417 and Ed448 together with with hash used[2] would be enough for
interop[3].

However, that will not be the CFRG signature scheme, whatever it is.

[1] The basepoint is clear for Curve41417. However, for Ed448, there
are two different basepoints:

1) The original basepoint from Ed448-Goldilocks:

x=0x297ea0ea2692ff1b4faff46098453a6a26adf733245f065c3c59d0709cecfa96147eaaf3932d94c63d96c170033f4ba0c7f0de840aed939f
y=0x13

2) Inverted (not dual) isogeny point to Curve448 basepoint:

x=0xB0E68F399412F212DDE2EA59DD40C92561EB9A8FB8F0E89815921CDA5C2C5B9BED51E508D5499AEEBCC47F1E74FF6C71D9D957D438F33FA1
y=0x693F46716EB6BC248876203756C9C7624BEA73736CA3984087789C1E05A0C2D73AD3FF1CE67C39C4FDBD132C4ED7C8AD9808795BF230FA14

This point B' has the property that (y/x)^2 of nth scalar multiple is
the nth scalar multiple of Curve448 basepoint (u=5). Which would
be handy if also working on Curve448, as fixed-base multiplier with
that point as base could be used to accelerate Curve448 key generation.

(One can see that (y/x)^2 of point given is 5).

[2] AFAICT:

- Near-PoT order -> At least 64 bits more than order.
- Otherwise -> maximum of 5/4 of order bits or 64 more.

All three curves have near-pot orders, so limits by that rule
would be:

Curve25519: >=317 bits (>=40 bytes)
Curve41417: >=475 bits (>=60 bytes)
Curve448: >=510 bits (>=64 bytes)

All three limits are less than 512, so 512-bit hash like SHA-512 would
work.

[3] Where interop means defining what verifier accepts, but not specifics
of signing.

-Ilari