Re: [dnsext] about ECDSA

[Paul Hoffman <[e-mail]>]

On Apr 6, 2012, at 8:09 AM, Francis Dupont wrote:

> - my Fedora 16 compiles OpenSSL with no Elliptic Curve support (and
>  of course no ECDSA). If someone wants to put some pressure to get
>  this fixed, I'll join!

This is a compile-time option for OpenSSL. If the version of OpenSSL that comes with Fedora 16 doesn't have the option, you can download a fresh version of OpenSSL and build it locally.

> - in http://www.iana.org/assignments/ds-rr-types/ds-rr-types.xml
>  SHA-384 is OPTIONAL. I believed the idea was to use it with the new
>  ECDSA keys, so this will have to be fixed in the long term. BTW how?

Recycling of political discussion; deferred.

> - I still have a question about the 256/384 pair: are they
>  supposed to be handled as two different algos (as RSASHA1 and
>  RSASHA256, or RSASHA256 and RSASHA512) or as the same algo
>  with two different "strengths"? Note at the beginning (i.e.,
>  when I asked this many months ago) it was only a concern for
>  the signer but according to a recent discussion it is concern
>  for resolvers too.

They are different algorithms with different strengths, so your either/or question doesn't make sense. Similarly, each of the defined SHA-2 variants are also different algorithms and each has a different strength.

> - I have the performance figures with the last OpenSSL (1.0.1)
>  and its new assembly support (aka enable-ec_nistp_64_gcc_128),
>  unfortunately not available for P384 (can't see why)?
>  ECDSA is really faster on signing and the verifying is still
>  reasonable, so Paul's prediction about EC support quality
>  was correct.

Good to hear.

> PS: I am not the right person to ask for ECDSA support in
> the next distribs (I don't say you shouldn't ask).

Diddling with OpenSSL in the various Linux distros may not be such a good idea...

> PPS: it should be good to get the examples with a date in
> the future.

Too late. :-)

--Paul Hoffman