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

Ryan Sleevi sleevi at google.com
Fri Dec 21 10:42:50 MST 2018


On Fri, Dec 21, 2018 at 11:42 AM Phillip <philliph at comodo.com> wrote:

> 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.
>

It sounds like there are areas of agreement, but to be clear, I think
there's a clear and important disagreement.

In your proposed ordering, #3 happens before any possible security
evaluation or consideration of what #4 means has been done. That seems
irresponsible, from a security point of view, which is why I was trying to
capture that the ordering is inverted - #4 is a precondition to #3.

I think Rob's questioning is helpful - which is to say, yes, there is
support for and demand for, if you can produce something that meets the
security requirements. However, history has shown us repeatedly, trying to
specify it abstractly and hoping folks get the security requirements right
is a dangerous, harmful thing. So show that it's possible to securely
protect keys, that there is some concrete thing to evaluate, and it's
reasonable to look at supporting.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181221/b5a60ef9/attachment.html>


More information about the Servercert-wg mailing list