Re: [Cfrg] ECC reboot

On 20/10/14 14:05, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 20 October 2014 10:40:47 BST, Rob Stradling <rob.stradling@comodo.com> wrote:
>
>> When we generated our ECC root CA keys in 2008, secp384r1 seemed like the best choice.  secp521r1 wasn't in Suite B, and it seemed likely that Suite B compliance would be a requirement for some of our customers.
>
> Why not secp256r1? (I'm guessing the big reason was because the TS profile required ≈WF192 and you wanted one root to be suitable for both profiles if you could?)

That was certainly part of the reason.  The other part was that a 
competitor had already chosen secp384r1, so it seemed safest to follow 
suit.  :-)

> It's a bit early to say, but (open question to all) if we picked one curve at ≈WF128, would you in principle be comfortable with having roots of that strength?

In principle, yes, but...

> What about if we picked two: one fast secure curve at 128 and one at some higher "paranoid" grade (be it 384, 448, 480, 512, 521, 607...)? Which would you perhaps consider using when? Would you have one root at each level, or a shared root at the paranoid level?

I'm inclined to agree with my colleague PHB, who wrote recently:
"The Web PKI will almost certainly be based exclusively on the ~512
level curve. The roots certainly will."

The various browser root programs place limits on the total number of 
roots per CA.  So whilst a ≈WF128 root could be useful, I think there's 
a very good chance that we won't have the option to embed both ≈WF128 
and ≈WF<paranoid> roots.

> What kinds of things would you need to be able to have such a root? I'm guessing, bringing it back home to the weekly topic, that 'high-assurance' crypto hardware of some form would be highly desirable for that. But what does that mean to *you*?

Yes, we would need at least one HSM that can generate keys and 
signatures on the new curves.  The speed of the implementation won't 
matter much.  If the new curves are to be used with ECDSA (unlikely?) 
then I think it might even be possible to persuade existing HSMs to do 
the job.  PKCS#11 supports ANSI x9.62 "EC domain parameters" as well as 
named curves, for example.

> I say this because I don't think the initial target market for these new curves necessarily includes those mandated to use Suite B (although never say never!), I don't think government approval will drive adoption this time, and also the assurances people ask of Web PKI CAs in particular seem to be strengthening considerably relative to where they were (cf: Certificate Transparency, et al).

Agreed.

>> TLS clients commonly don't specify RSA/SHA-512 and ECDSA/SHA-512  in the TLS signature_algorithms extension.  Some servers respond by refusing to serve certs with SHA-512 signatures.
>
> Thanks for that note. The TLS WG and user-agent participants should probably bear this in mind, down the line, if whatever we come up with is to be accepted and used.
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
> Version: APG v1.1.1
>
> iQI3BAEBCgAhBQJURQiIGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE
> jtkWi2t6lFAP/04NXnjKWHI34cZ2OYIs+qCP4q35hKFvbtAX+7MECPmlF+4lrpbS
> /Hzu8bjjsLVphsTWbXo8bW7sXCLWzHGkcL4QuvZM56ArngvP17EK3tZIgkFiOjKY
> D+hlGskjcAgXDhRvyaEvimuUHQ9BVWmGft0XPnMSucBckq634Bbw3VSdzhq+0yAV
> 5awXzKeTkrI9sYrwSXZ/P9TN/ejVjfI0t3KU+RxdMPWTY8psbmXsuaMT8ny4EkOi
> PhskwFNb5rndfRBEq/rnenhXAgTnUJVf51vBhU8YOKZLy2NojcZ2Wjy5YOQuDepQ
> GE3phWRqxCA4hnhbnNHcguxnlh5B6y5OzEYd/9/Iaia/brj7H3eYvc84RnG1H9Fl
> VTkBrAZUUmtcmdnTlNnEBQQ/pmSlGWZsIhLYPueXD43yAggMvP8YffURKADFfm6J
> Om5BmI2JVWjFpDjQA7e9NKL6niTJUccqUkHNjm54wEwIuh0zcKJCBzZ4P4cUU+vk
> T5BDy3AoVLFT9uVOXV/vXkTA3xcOtlLaUgnTa3CzRR9IuoIewPncK1MurP6I37jA
> XzcupAFmTgiDcITjKAm2xzaVzJwWByBbtuvaMBKRFbA1UK++y9/YWnhalwsEmNYf
> lo5LnvTuJa/SvmPcpLHqtqeTIIV3rWVdn5GVbZOx5jxao5KK19b/7kMF
> =tB0e
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.