Subject: Re: [Cfrg] Elliptic Curves - signature scheme (ends on April 22nd)

From: Rick Andrews <[email-masked]>
Date: Fri, 10 Apr 2015 14:41:01 -0700

dkg wrote:

"Reasonable CAs will figure out how to deploy certificates that use a new
scheme that we endorse.  Deployment may take slightly longer by choosing
a new scheme, but this is a worthwhile price to pay if it means avoiding
pitfalls in implementation security for the long term."

CAs are not often the trailblazers here. In general, we don't write our own crypto algorithms; we use software toolkits and HSMs. We can't start signing certs with a new algorithm until our software and hardware suppliers build it in. And they probably won't do that until they see some demand. And of course, the new algorithm must be supported by browsers and web servers. 

-Rick

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 10 Apr 2015 15:26:31 -0700

> On Apr 10, 2015, at 2:41 PM, Rick Andrews <[email-masked]> wrote:
> 
> We can't start signing certs with a new algorithm until our software and hardware suppliers build it in.

You can probably sign (certs with a new algorithm) without hardware support, right?  You just can’t (sign certs) with a new algorithm?

That is, you could have the CA key be ECDSA, and the PK in the cert be *25519, right?

— Mike

---

From: Rick Andrews <[email-masked]>
Date: Fri, 10 Apr 2015 15:39:35 -0700

Correct. But we'd have to think carefully about whether that's wise to do (mix algorithms). If CFRG is going to specify a better ECC-based signing algorithm, I would think we'd want to use it consistently.

-Rick

-----Original Message-----
From: Michael Hamburg [mailto:[email-masked]] 
Sent: Friday, April 10, 2015 3:27 PM
To: Rick Andrews
Cc: [email-masked]
Subject: Re: [Cfrg] Elliptic Curves - signature scheme (ends on April 22nd)

— Mike

---

From: Michael Hamburg <[email-masked]>
Date: Fri, 10 Apr 2015 16:38:16 -0700

Ah, I see.  But would it help you (or your vendors) at all if we chose ECDSA-Curve25519?  I would expect that to be at least as hard to implement and test as Schnorr-Curve25519, even if you already have code for ECDSA-NIST-P256.

— Mike

> On Apr 10, 2015, at 3:39 PM, Rick Andrews <[email-masked]> wrote:
>

---

From: Annie <[email-masked]>
Date: Sat, 11 Apr 2015 03:42:57 +0200

Each algorithm has its own strength and e.g., RSA-4096 and ECC-256 have
comparable security levels (see www.keylength.com). IMHO there is no
inconsistency in choosing one signing algo for a subject public key of
another algo type. It's a burden for the RP, but not at all an algo mixing.
And no standard require the use of only one algo type or only one keylength.
/Ann.

Am 11.04.2015 um 01:33 schrieb Rick Andrews:
> I would say it is inconsistent, yes. I'm not a cryptographer, so I don't know if mixing two algorithms makes the certificate stronger or weaker.
>
> From: Annie [mailto:[email-masked]] 
> Sent: Friday, April 10, 2015 4:23 PM
> To: Rick Andrews
> Am 11.04.2015 um 00:39 schrieb Rick Andrews:
>> Correct. But we'd have to think carefully about whether that's wise to do (mix algorithms). 
> Rick,
> and what about an ECC key certified by an RSA signature?
> Is this also an inconsistent mixing?
> /Ann.
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 11 Apr 2015 03:32:42 +0000

On Fri, Apr 10, 2015 at 02:41:01PM -0700, Rick Andrews wrote:

> CAs are not often the trailblazers here. In general, we don't
> write our own crypto algorithms; we use software toolkits and HSMs.

The HSMs don't initially need to support the new algorithms, you
can issue certificates whose public keys use new crypto, that are
signed by RSA issuers.

> and hardware suppliers build it in.

Therefore, the hardware support is not an immediate barrier, but
you do need to be able to validate signatures in CSRs, so the
software side does need to catch up.

> And they probably won't do that until they see some demand. And of course,
> the new algorithm must be supported by browsers and web servers.

I expect demand won't take too long, the various cloud infrastructure
providers and browser vendors will be fairly keen to trumpet support
for modern untainted crypto.

On Fri, Apr 10, 2015 at 03:39:35PM -0700, Rick Andrews wrote:

> Correct. But we'd have to think carefully about whether that's wise to do
> (mix algorithms). If CFRG is going to specify a better ECC-based signing
> algorithm, I would think we'd want to use it consistently.

Nah, go for it!  Transitions require impure approaches to avoid
flag-days.  It'll take a while before any new trust-anchors are
widely employed, in the mean time you can start giving early adopters
the ability to use modern crypto in their leaf certs.

-- 
	Viktor.

---

From: Rick Andrews <[email-masked]>
Date: Tue, 14 Apr 2015 11:56:48 -0700

Mike,

> That is, you could have the CA key be ECDSA, and the PK in the cert be *25519, right?

I just want to clarify that we can't just sign any unknown key blob. CAs have to do proof of possession, by verifying the signature on the CSR. We can't do that unless the hardware or software toolkit we're using for signature verification supports the curve. So we can't today sign a PK from 25519 with ECDSA.

-Rick

---

From: Yoav Nir <[email-masked]>
Date: Tue, 14 Apr 2015 23:47:59 +0300

Hi, Rick

> On Apr 14, 2015, at 9:56 PM, Rick Andrews <[email-masked]> wrote:
> 
> Mike,
> 
> You said:

Understood, but am I correct in surmising that the PoP checking is less sensitive than the signing?  I mean that in the sense that you can update your software to check EdDSA signatures with Curve25519 fairly easily, but actually issuing a EdDSA sub-CA and signing certificates with that algorithm would be a bigger deal, i.e. require certified hardware, require a decision by the CA/BF or some such?

Thanks

Yoav

---

From: Rick Andrews <[email-masked]>
Date: Tue, 14 Apr 2015 13:57:34 -0700

Yoav, that's correct. The CA/Browser Forum Baseline Requirements limits us to the NIST Suite-B curves. For that to be expanded, the browser vendors would have to agree to build in support for new curves. If that happens, updating the Baseline Requirements is mostly a formality.

-Rick

-----Original Message-----

Thanks

Yoav

---

From: Dan Brown <[email-masked]>
Date: Tue, 14 Apr 2015 20:58:17 +0000

> Rick Andrews
> > > You can probably sign (certs with a new algorithm) without hardware
> support, right?  You just can’t (sign certs) with a new algorithm?
> I just want to clarify that we can't just sign any unknown key blob. CAs have to
> do proof of possession, by verifying the signature on the CSR. We can't do that
> unless the hardware or software toolkit we're using for signature verification
> supports the curve. So we can't today sign a PK from 25519 with ECDSA.
> 

[DB] This is the kind of situation where a generic-curve implementation might help.

---

From: "Mehner, Carl" <[email-masked]>
Date: Tue, 14 Apr 2015 21:07:41 +0000

The only issue I can see with signing any new curved certificates with RSA
is that any strict implementation of TLS 1.1 [1] and configurations that
have to adhere to NIST's TLS document [2] would potentially break (or simply
not be able to use these certificates).

[1] http://tools.ietf.org/html/rfc4346#section-7.4.2

                        Unless otherwise specified, the signing
algorithm for the certificate MUST be the same as the algorithm
for the certificate key.

[2]
http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf

Certificates containing RSA (key encipherment or signature), ECDSA, or DSA
public keys shall be signed with those same signature algorithms,
respectively;

> From: Cfrg [mailto:[email-masked]] On Behalf Of Rick Andrews
> Sent: Tuesday, April 14, 2015 3:58 PM
> To: Yoav Nir
> Cc: [email-masked]
> Yoav, that's correct. The CA/Browser Forum Baseline Requirements limits
> us to the NIST Suite-B curves. For that to be expanded, the browser
> vendors would have to agree to build in support for new curves. If that
> happens, updating the Baseline Requirements is mostly a formality.
> 
> -Rick
> 
> > I just want to clarify that we can't just sign any unknown key blob.
> CAs have to do proof of possession, by verifying the signature on the
> CSR. We can't do that unless the hardware or software toolkit we're
> using for signature verification supports the curve. So we can't today
> sign a PK from 25519 with ECDSA.
> 
> Understood, but am I correct in surmising that the PoP checking is less
> sensitive than the signing?  I mean that in the sense that you can
> update your software to check EdDSA signatures with Curve25519 fairly
> easily, but actually issuing a EdDSA sub-CA and signing certificates
> with that algorithm would be a bigger deal, i.e. require certified
> hardware, require a decision by the CA/BF or some such?
> 
> Thanks
> 
> Yoav
> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/cfrg

---

From: Yoav Nir <[email-masked]>
Date: Wed, 15 Apr 2015 00:17:56 +0300

> On Apr 15, 2015, at 12:07 AM, Mehner, Carl <[email-masked]> wrote:
> 

Yeah, Peter Gutmann has said multiple times that all sensible implementers ignored this. I guess that makes me a sensible implementer.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Apr 2015 17:57:02 -0500

On Fri, Apr 10, 2015 at 03:39:35PM -0700, Rick Andrews wrote:
> Correct. But we'd have to think carefully about whether that's wise to
> do (mix algorithms). If CFRG is going to specify a better ECC-based
> signing algorithm, I would think we'd want to use it consistently.

Obviously there's no problem with the TBSCertificate's subject public
key's signature algorithm and the issuer's.

Also obviously, if we want to move to a new signature scheme then we'll
want to get support for it up and down the certificate chains so that we
can eventually deprecate older signature schemes.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Apr 2015 17:58:27 -0500

> can issue certificates whose public keys use new crypto, that are

+1.  (I assume all HSMs will have RSA support.  I think that's a safe
and fair assumption.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Apr 2015 17:59:15 -0500

On Fri, Apr 10, 2015 at 04:38:16PM -0700, Michael Hamburg wrote:
> Ah, I see.  But would it help you (or your vendors) at all if we chose
> ECDSA-Curve25519?  I would expect that to be at least as hard to
> implement and test as Schnorr-Curve25519, even if you already have
> code for ECDSA-NIST-P256.

We shouldn't merely swap curves.  We should get away from the
requirement for random numbers.

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Apr 2015 18:24:33 -0500

On Tue, Apr 14, 2015 at 01:57:34PM -0700, Rick Andrews wrote:
> Yoav, that's correct. The CA/Browser Forum Baseline Requirements
> limits us to the NIST Suite-B curves. For that to be expanded, the
         ^^
"us" != CFRG in that sentence.

CFRG can do what it likes, and other organizations (and IETF WGs) can do
what they like.  We're talking about what we == CFRG should do, and why.

> browser vendors would have to agree to build in support for new
> curves. If that happens, updating the Baseline Requirements is mostly
> a formality.

They're already going to be building in support for new curves for ECDH
(Curve25519)...

Nico
--

---

From: Rick Andrews <[email-masked]>
Date: Thu, 16 Apr 2015 17:20:16 -0700

-----Original Message-----
From: Nico Williams [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 4:25 PM

         ^^

CFRG can do what it likes, and other organizations (and IETF WGs) can do what they like.  We're talking about what we == CFRG should do, and why.

[Rick] Right. I should have been more clear. I was speaking as a Certificate Authority, and "us" refers to the group of public CAs bound by the CA/Browser Forum Baseline Requirements.

-Rick

---

From: Erwann Abalea <[email-masked]>
Date: Fri, 17 Apr 2015 12:33:14 +0200

> They're already going to be building in support for new curves for ECDH

And the CAs don't care about the curves used for ECDH(E) between the TLS 
server and the TLS client. So there's no constraint in the Baseline 
Requirements on such curves and key exchange schemes.

-- 
Erwann ABALEA

---

From: Nico Williams <[email-masked]>
Date: Fri, 17 Apr 2015 10:01:21 -0500

On Fri, Apr 17, 2015 at 12:33:14PM +0200, Erwann Abalea wrote:
> And the CAs don't care about the curves used for ECDH(E) between the
> TLS server and the TLS client. So there's no constraint in the
> Baseline Requirements on such curves and key exchange schemes.

Rick was talking about browser vendors.