[Servercert-wg] Ed25519 in certificates

[Ryan Sleevi]

On Tue, Jun 25, 2019 at 1:41 PM Tim Hollebeek via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> What do people think about a ballot allowing certificates based on
> Ed25519?  It’s widely supported, more efficient, and more resistant to side
> channel attacks.  It’s supported by Boring SSL and OpenSSL, as well as
> other popular crypto libraries.  It’s been standardized at IETF (RFC 8032),
> and TLS 1.3 (RFC 8446) not only supports it, but encourages its use.  Some
> customers prefer non-NIST curves for various reasons.  It’s already widely
> used for DNSSEC … the Web PKI is falling behind, as usual.
>

I feel like we've hashed this out now several times at F2F, including what
the practical steps for deployment look like. Nothing's really changed here.

There are a number of dimensions here:
- Leaf certificates vs signing certificates (particularly relevant for key
protection)
- The expression of the SPKI (breaks a number of libraries, including all
versions of Chrome and Safari, for example)
- The benefits (slight speed) versus the cost

As a practical matter, the incremental benefit is very limited, the amount
of work to support it in any deployable fashion is actually rather
significant, the usability is fairly limited (leaf certs only).

I fundamentally disagree on the "widely supported" claim. It only
"recently" landed in OpenSSL and Golang. BoringSSL's support is not used by
any (known) shipping user of BoringSSL; it was incidentally picked up by
virtue of supporting Ed25519 at a lower level. You can see extensive
discussion within the IETF TLS WG during the standardization of TLS 1.3
about the compatibility challenges provided here by the introduction of new
subjectPublicKeyInfo types, and that's why TLS 1.3 itself has some
interesting advertising.

It seems there's also three questions:
1) Is it worth permitting by the BRs? (and whether for leaves or
intermediates or both)
2) Is it worth permitting by the root stores? For example, DSA is permitted
by the BRs, but functionally not permitted by root stores.
3) Is it worth encouraging for use?

1 isn't that worthwhile without 2, and 2 isn't that worthwhile given the
compat issues. 3 isn't that worthwhile, given that we know the real effort
and energy and migration should be spent, from an implementer and a CABF
perspective, on the PQ problem. Hybrid schemes are tantalizing, and
improving performance of hybrid schemes is crucial, so perhaps there is a
path where Ed25519 is a valuable part of a hybrid scheme. Yet just as we
talked at the recent F2F about other expressions of certificate assertions,
and just as we talked in the past IETF about other provenance of signatures
or certificates for TLS handshakes, perhaps that's something worth
exploring?

It's certainly appealing to frame it as the WebPKI falling behind - but, as
a practical matter, the benefits are significantly outweighed by the costs,
due to how marginal they are. There's an appeal to be made on a "We don't
trust NIST", but we've been down that road as well.

So, no, there's not a lot of benefit. As we've captured in the past. See
Seattle and Raleigh/Durham F2F minutes, and plenty past on the list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190625/9257844e/attachment.html>