[Servercert-wg] [cabfpub] Interest in Ed25519 and/or Ed448?

Tim Hollebeek tim.hollebeek at digicert.com
Fri Dec 21 10:09:17 MST 2018

I actually took Shor’s course last winter.  It’s excellent, and I recommend doing the homework so you see how everything works.  It doesn’t require anything more than basic linear algebra.




From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Phillip via Servercert-wg
Sent: Friday, December 21, 2018 11:43 AM
To: 'Ryan Sleevi' <sleevi at google.com>; 'CA/B Forum Server Certificate WG Public Discussion List' <servercert-wg at cabforum.org>; 'Rob Stradling' <rob at sectigo.com>
Subject: Re: [Servercert-wg] [cabfpub] Interest in Ed25519 and/or Ed448?


One major concern I have in any standards process covering multiple bodies is to avoid a standards deadlock condition in which each group is waiting for another to act.


As far as CABForum is concerned, the existence of FIPS qualified hardware should be irrelevant to passing a BR. If we want FIPS hardware, we say it is a requirement in the BR.


If we wait for the hardware manufacturers to deploy, they will wait for us and so on ad infinitum. We have a circle of ungranted request. The way I see this process working is:


1.	IRTF-CFRG examines, reviews and specifies algorithms
2.	IETF-TLS specifies code points for use in TLS
3.	CABForum approves use in WebPKI certificates
4.	Vendors deploy


Each step in the process can only wait on lower numbered steps.


Here Vendors includes browser providers, CAs and HSM manufacturers. Since HSM manufacturers are not represented in CABForum, it would be especially futile to wait on them. So we make a requirement now knowing it will take them some time to catch up. In the meantime, browsers can start writing and testing code.


I am not that confident about public key being relevant to the WebPKI in the near term. I have a suspicion that either we will discover that quantum computing does not offer an exponential scaling advantage like VLSI has or we will make a breakthrough discovery that suddenly unlocks multiple levels at once. So either the pace of change will be too slow to worry about or so fast that we have to think about Needham Schroeder and Harber Stornetta/Lamport type solutions which is what I am going to be focusing on in the next few years when I leave Comodo.


MIT is doing an online course on Quantum Computing that some folk may be interested in. I am taking it myself because having absorbed the information piecemeal over the course of a decade, I think it would be useful to see how Shor an co structure the material.





From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto:servercert-wg-bounces at cabforum.org> > On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Friday, December 21, 2018 10:47 AM
To: Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> >
Subject: Re: [Servercert-wg] [cabfpub] Interest in Ed25519 and/or Ed448?




On Fri, Dec 21, 2018 at 10:29 AM Rob Stradling <rob at sectigo.com <mailto:rob at sectigo.com> > wrote:

Do you have a clear list of targets that would need to be met for 
Ed25519/Ed448 to be "useable in the contexts" that you "are concerned 


Hah, nice quotes. I mean, I'm limiting the scope to TLS certificates ;)


For example, are you waiting for Ed25519/Ed448 to become incorporated 
into FIPS-140 certifications?  Or would it be enough for just one HSM 
vendor to ship support for Ed25519/Ed448 in at least one model of HSM, 
and for that HSM to be operated in "non FIPS mode"?

Or is it too early to be asking these questions?


So we've had these conversations in the past - most notably, at the RTP F2F hosted by Cisco last year. Having looked at a variety of HSMs in the past, there was discussion about how the "non-FIPS approved mode" can cause all sorts of shadiness - including not zero-izing keys on erasure, for example. During the Herndon F2F hosted by Amazon, there was again a resurgence in discussion about what it would take for these algorithms to find a happy path to being in a FIPS-approved mode of operation; for example, the discussion talked about whether HSMs wholly disable non-CAVP validated algorithms / those not approved for FIPS-approved mode, or whether the device itself behaved in a FIPS-approved mode of operation, and this was merely a deviation from the security policy by the operator.


I don't think it's too unreasonable a suggestion; there seemed to be pretty wide-spread agreement during the many past conversations on the topic of algorithms that the sort of base-level assurance is that the key is reasonably protected, in a way that can be consistently and independently verified (e.g. through a well-respected, internationally recognized program like the CMVP process fits into).


And without wanting to move the goal post, there's definitely some concern about the level of work versus the return. My colleague, Adam Langley, has written about the work going on at Google and in Chrome, in partnership with others, to explore post-quantum key exchange in the context for TLS - https://www.imperialviolet.org/2018/12/12/cecpq2.html - and as he notes in the coda, the PKI ecosystem is going to take a huge amount of work to get there as well. Our interest in Ed25519/Ed448 is, in part, as a way of making sure we can execute on that process and work out issues now, with an algorithm we have - While Ed25519/Ed448 would be nice, they're not pressing in the way that PQ is, but they're a reasonable and available way for the ecosystem to start taking steps to work out these inter-dependencies and moving.


Hopefully that helps provide more color and context: to the priorities, the concerns, and the challenges.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181221/291531c2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181221/291531c2/attachment-0001.p7s>

More information about the Servercert-wg mailing list