Re: [Cfrg] Curve manipulation, revisited

Rob Stradling <> Mon, 29 December 2014 21:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CCC841A910B for <>; Mon, 29 Dec 2014 13:11:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Gt8EZI8UeZDN for <>; Mon, 29 Dec 2014 13:11:52 -0800 (PST)
Received: from ( [IPv6:2a02:1788:402:c00::c0a8:9cd6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7DC241A90D3 for <>; Mon, 29 Dec 2014 13:11:47 -0800 (PST)
Received: (qmail 19364 invoked by uid 1004); 29 Dec 2014 21:11:45 -0000
Received: from (HELO ( by (qpsmtpd/0.84) with ESMTP; Mon, 29 Dec 2014 21:11:45 +0000
Received: (qmail 24695 invoked by uid 1000); 29 Dec 2014 21:11:45 -0000
Received: from (HELO []) ( (smtp-auth username rob, mechanism plain) by (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Mon, 29 Dec 2014 21:11:45 +0000
Message-ID: <>
Date: Mon, 29 Dec 2014 21:11:44 +0000
From: Rob Stradling <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Yoav Nir <>, Rich Salz <>
References: <><><><><><><><><><><> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [Cfrg] Curve manipulation, revisited
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 29 Dec 2014 21:11:56 -0000

On 29/12/14 20:08, Yoav Nir wrote:
>> On Dec 29, 2014, at 9:53 PM, Salz, Rich <> 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,


> 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 

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