Re: [Cfrg] ECC reboot

Rob Stradling <rob.stradling@comodo.com> Thu, 23 October 2014 20:43 UTC

Return-Path: <rob.stradling@comodo.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6D21AD3D2 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 13:43:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.29
X-Spam-Level:
X-Spam-Status: No, score=-1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_NET=0.611, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W0vUI4r4oHJ2 for <cfrg@ietfa.amsl.com>; Thu, 23 Oct 2014 13:43:55 -0700 (PDT)
Received: from ian.brad.office.comodo.net (eth5.brad-fw.brad.office.ccanet.co.uk [178.255.87.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22A391AD3E2 for <cfrg@irtf.org>; Thu, 23 Oct 2014 13:43:54 -0700 (PDT)
Received: (qmail 1794 invoked by uid 1000); 23 Oct 2014 20:43:51 -0000
Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Thu, 23 Oct 2014 21:43:51 +0100
Message-ID: <54496886.2040807@comodo.com>
Date: Thu, 23 Oct 2014 21:43:50 +0100
From: Rob Stradling <rob.stradling@comodo.com>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Alyssa Rowan <akr@akr.io>, "cfrg@irtf.org" <cfrg@irtf.org>
References: <D065A817.30406%kenny.paterson@rhul.ac.uk> <54400E9F.5020905@akr.io> <CAMm+LwhVKBfcfrXUKmVXKsiAMRSTV+ws+u07grmxkfnR2oYJoQ@mail.gmail.com> <5218FD35-E00A-413F-ACCB-AA9B99DEF48B@shiftleft.org> <m3r3y6z3z8.fsf@carbon.jhcloos.org> <CA+Vbu7x4Y_=JZ9Ydp=U5QnJokL28QMQnV4XUn9S6+CUZR9ozEw@mail.gmail.com> <5444D89F.5080407@comodo.com> <90C609A5-ECB2-4FDC-9669-5830F3463D2B@akr.io> <5448DBE2.10107@comodo.com><CACsn0cne95adtTbCf6WyAZGyCSyLXo5L0302rm7238yHAsE5EQ@mail.gmail.com> <54493DB1.5070204@akr.io>
In-Reply-To: <54493DB1.5070204@akr.io>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/cfrg/xY7uy5pFjNdFILtvF3bGIc6hfhY
Subject: Re: [Cfrg] ECC reboot
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Oct 2014 20:43:58 -0000

On 23/10/14 18:41, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 23/10/2014 15:27, Watson Ladd wrote:
>
>>> 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."
>> Previously, when given a choice of curves, the one with size 384 or
>> thereabouts was picked. Now you are saying you want the biggest
>> possible curve, regardless of the performance impact.
>
> Not wishing to speak for Rob, but what I _think_ he means here is simply
> that if there was one curve picked, he'd use it in principle; but given
> the choice between two curves (a strong fast curve, and a paranoid
> curve), he'd probably be tempted to go for the paranoid one for the roots?

Yes.

<snip>
> By the way, as a matter of practicality, would we perhaps be looking at
> some kind of hybrid transition period where existing ECDSA-P384-SHA384
> roots sign (purely by way of example) EdDSA-Curve25519-SHA512 end-entity
> certificates?

Either that or existing RSA roots cross-certifying next generation ECC 
roots.

> How would the choice of end-entity algorithms be
> restrained by the signing algorithms and curves used on the roots, or
> not? (I appreciate that may not really be a question for here, but for
> upstream in TLS or PKIX.)

Not.

BTW, we're in a hybrid transition period at the moment: our 
ECDSA-P384-SHA384 roots are cross-certified by our old RSA roots.

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