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

[Ryan Sleevi]

On Fri, Dec 21, 2018 at 10:29 AM Rob Stradling <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
> about"?
>

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/a1a55d23/attachment.html>