Re: [Cfrg] Curve manipulation, revisited

[Rob Stradling <[e-mail]>]

On 29/12/14 20:08, Yoav Nir wrote:
>
>> On Dec 29, 2014, at 9:53 PM, Salz, Rich <[e-mail]> wrote:
>>
>>> Not to get all Watson on you, but does that mean you don't have a strong opinion on the twisted Edwards form?
>>
>> I don't consider myself qualified enough to have an opinion worth stating.
>
> Me neither, but I would like the CFRG to come up with a signature algorithm and compatible curves for TLS / IKE / SSH. Deployment will be far slower. We need CFRG to recommend before TLS specifies, and TLS will specify before the browsers implement,

+1

> and the CAs won’t sign certificates with such keys before the vast majority of browsers support.

I hope that CAs will be ready and willing to sign such certs sooner than 
that.

There might not be huge demand for such certs until there is widespread 
browser support, but I expect there will be some demand.  And if there 
is some demand then CAs may as well add support for the CFRG-blessed 
curves and signature algorithms ASAP.  We won't even need to wait for 
new HSMs in order to issue such certs from our existing RSA and ECDSA 
issuing CAs.

Some TLS server software (notably Apache httpd) can already use several 
certs for the same hostname, where each cert has a different public key 
algorithm (RSA, DSA, ECC).  This means that certs with P-256 and P-384 
public keys can be used where there is browser support, with fallback to 
certs with RSA public keys for the long tail of non-ECC-capable browsers.
I'd like to think that it wouldn't be too hard to make this sort of 
mechanism also support certs with keys on the new CFRG curve(s).

> This is not like a new ECDHE curve where anyone can add it to their implementation.
>
> Yoav

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online