[dnsext] about ECDSA

[Francis Dupont <[e-mail]>]

I am refreshing the ECDSA experimental support in bind9 so
I have some random comments:

 - 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!

 - 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?

 - 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.

 - 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.

Regards

[e-mail]

PS: I am not the right person to ask for ECDSA support in
the next distribs (I don't say you shouldn't ask).
PPS: it should be good to get the examples with a date in
the future.
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext