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

[Mehner, Carl]

(Sorry for top-posting … outlook isn’t great for mail forums).
That quote was referring to Tim H saying that because we weren’t using Ed25519, the Web PKI was behind, you replied saying that it should be framed as a practical matter around cost [1].
Based on the minutes you linked to, I can see how different conclusions can be reached on the best way forward 1) deploying a new SPKI now to find things that will break and need new libraries, or 2) waiting until the PQC algorithm decision is made before testing new cert types.
In my mind, working on things that we agree are secure now (Ed25519) in order to sus out incompatibilities can help us when it is time to deploy PQC-certs in the future. I would argue that it is important to do this now because we do not know how long the PQC decision will take nor how long we have until PQC is an imminent threat requiring change. Given enough time, testing, and motivation, I think people can be ready for a PQC transition in server certificates. If the testing waits until PQC is needed, we won’t find issues until it’s too late. Changing to a new SPKI now helps us have a longer runway for testing new algorithms to help companies/people find what technologies will be affected by other non-optional algorithm changes in the future and begin working with their vendors and upgrade plans now rather than later.

-carl

[1] https://cabforum.org/pipermail/servercert-wg/2019-June/000875.html

On 3/26/20, 11:25 AM, "Ryan Sleevi" <sleevi at google.com<mailto:sleevi at google.com>> wrote:

On Thu, Mar 26, 2020 at 12:03 PM Mehner, Carl <Carl.Mehner at usaa.com<mailto:Carl.Mehner at usaa.com>> wrote:
Hi Ryan,

From: Ryan Sleevi via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>
> It looks like you snipped some of the follow-up discussion that clarified this. Was that intentional?

I recall you mentioned, “the benefits are significantly outweighed by the costs” but it appears that you neglected to say what those costs were. That said, there’s also a note about hashing this subject out in F2F meetings, so there may be more behind that than what’s available on this mailing list (I couldn’t find anything in meeting minutes either that seems to adequately address this).

I'm not sure where that quote is being attributed to?  The specific discussion continued at https://cabforum.org/pipermail/servercert-wg/2018-December/000484.html<https://urldefense.com/v3/__https:/cabforum.org/pipermail/servercert-wg/2018-December/000484.html__;!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLJxo1--o$> , and shows why the framing that was proposed by Phillip (and endorsed by Kurt's reply) was problematic.

In terms of F2F discussions, this was discussed pretty extensively at Meeting 39 - https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Non-FIPS-algorithms-for-customer-public-keys-and-certificate-signing<https://urldefense.com/v3/__https:/cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/*Non-FIPS-algorithms-for-customer-public-keys-and-certificate-signing__;Iw!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLt2mcLqs$> - and continued at Meeting 40 - https://cabforum.org/2017/03/22/2017-03-22-f2f-meeting-40-minutes/#Process-for-Adoption-of-Post-SHA-2-Algorithms<https://urldefense.com/v3/__https:/cabforum.org/2017/03/22/2017-03-22-f2f-meeting-40-minutes/*Process-for-Adoption-of-Post-SHA-2-Algorithms__;Iw!!GryZGb6B1VCs0SfC!W97CooUS9y3790YcKTAle2IZ-rGT2zSgfrvBuakPXttAcHqqHXUd1KjLuybG6-k$>

The IETF TLS WG discussed at length the challenges with SPKI algorithms, in the context of a much older algorithm - RSA-PSS - and the compatibility and interoperability problems that can be had. This is why the TLS 1.3 design is what it is.