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

[Ryan Sleevi]

Right,

To be clear, it is less a concern of the CAVP side (although that does
provide very valuable data), and more concerned about the fact that
real-world devices in a fully-non-FIPS-approved mode of operations can end
up being less about "HSM" and more about "Like USB".

The discussions of this, as I mentioned, go back some time in the Forum -
Meeting 39 in Redmond spent some time discussing this [1]. It doesn't seem
like any progress has been made on this front since that discussion two
years ago.

[1]
https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Non-FIPS-algorithms-for-customer-public-keys-and-certificate-signing

On Fri, Dec 21, 2018 at 1:06 PM Paul Hoffman via Servercert-wg <
servercert-wg at cabforum.org> wrote:

> On Dec 21, 2018, at 9:42 AM, Ryan Sleevi via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
> >
> >
> > 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:
> >
> >
> >
> >       • IRTF-CFRG examines, reviews and specifies algorithms
> >       • IETF-TLS specifies code points for use in TLS
> >       • CABForum approves use in WebPKI certificates
> >       • 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.
>
> Maybe there is a step 3.5: "Potential HSM buyers ask their vendors whether
> they will support the new algorithm as well as they do the current ones".
>
> Just to be clear: an HSM vendor *can* pay their independent test lab to
> test their implementation of a not-yet-CMVP-supported algorithm, and *can*
> show the results of those tests to potential customers (depending on their
> agreement with their lab). At least in the past, it was common to test
> systems that have not-yet-CMVP-supported algorithms and those test results
> were sent to NIST even though they would not appear in the certificates.
>
> --Paul Hoffman_______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> http://cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20181221/4d5cfa85/attachment-0001.html>