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

[Ryan Sleevi]

On Thu, Dec 20, 2018 at 6:53 AM Rob Stradling via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> Maybe I can't ask that secondary question until after the Code Signing
> and S/MIME WGs have been chartered.
>

Right, I would expect that even if we had such a list, cross-posting would
be discouraged / prohibited, given the nature of both IPR commitments and
given that we should not assume all members will be in all WGs. At the
present, it seems best that any discussions outside of Forum-level business
or chartering of WGs would best be discussed on the applicable WG.

Despite being an "easy" question about what you're asking, there's actually
two questions/parts to unpack.

1) Do browsers have plans to support Ed25519/Ed448 SPKIs in leaf
certificates?
2) Do browsers have plans to support Ed25519/Ed448 signatures anywhere in
the certificate chain (which implies SPKIs in non-leaf certificates)?

I think any discussion about what that means has to consider the
discussions in the IETF TLS 1.3 WG regarding RSA-PSS, as the nuances and
trade-offs are the same. Those discussions highlighted the tendency of some
cryptographic libraries to choke on leaf SPKIs they don't recognize - even
if the client implementation may allow them - and the challenges with
deploying new signature algorithms in certificates vs TLS.

On the basis of the strong, widespread, International community review and
consensus in evaluating these algorithms, as captured through the
discussions of the IETF and CFRG, we're supportive of these algorithms and
would like to support them in Chrome.

Regarding the first question, our integration with certain OS cryptographic
functions to enable easier administration and "out of the box" experience
for Enterprises and home users presents some challenges to that support, as
alluded to above, and so we have nothing concrete to share at this time
beyond that expression of support and eventual intent.

Regarding the second question, we are still awaiting discussions about how
to best produce such signatures while still ensuring the keys used to
produce such signatures are reasonably, meaningfully, and demonstrably
protected. Until we see work progressing on those protection profiles,
we're concerned that shipping such support may be seen as encouraging
weaker standards for key protection, given that is the only way to produce
such signatures. While the dependencies overlap with those of the first
question - that is, they are certainly a technical precondition - we're
unlikely to enable support for a signature algorithm prior to it being
usable in the contexts we are concerned about, and we're unlikely to
support it being usable in the contexts we are concerned about without
there being a path to ensure meaningful, widely-accepted key protection in
those contexts.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181220/b459ce4e/attachment-0001.html>