Re: [Cfrg] Requirements for curve candidate evaluation update

[Phillip Hallam-Baker <[e-mail]>]

On Thu, Aug 14, 2014 at 1:49 AM, Alyssa Rowan <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 14/08/2014 03:42, Phillip Hallam-Baker wrote:
>
>> To be clear, I am arguing that we put HSM support way ahead of a
>> single model. HSM support is essential, a single model is
>> someone's idea of tidiness.
>
> That is a null property. Anything we can specify can be implemented in
> software or hardware. As I said before, there will _eventually_ be new
> HSMs, and new HSM firmware. People have already begun work on that.

What the constraint means is that if we come down to two curves and
little to choose between them and there is a significant difference in
the HSM situation then the curve that allows re-use of existing HSMs
wins, if neither does that then the curve that has support from HSM
manufacturers wins.

So folk peddling a curve would do well to line up HSM vendor support.


It isn't quite true to say that you can do everything in hardware or
software. There are very specific constraints here to do with side
channels and IPR that could have a huge bearing on what curve families
are viable and which are not.


> The commercial world of this are however glacially slow-moving, partly
> due to onerous and ineffective governmental certification requirements
> (one of the things that has been - rightly - criticised). Several do
> not support ECDSA (or ECDHE, where applicable) properly or at all, and
> this is why RSA is still far more common in the wild and ECDSA is
> quite honestly barely used by anyone publicly (there are _very few_
> ECDSA PKIX roots...) - those that are using it are running it in
> software and are therefore not relevant to your 'essential' requirement.

There are very few serious CAs. So its not surprising there are few
ECC roots. We have ECC roots, so do the other leading CAs. But the
reason for the lag has been IPR FUD.