[openssl-project] OpenSSL 3.0 and FIPS Update

[Richard Levitte]

On Thu, 21 Feb 2019 17:20:53 +0100,
Matt Caswell wrote:
> On 21/02/2019 15:02, Dmitry Belyavsky wrote:
> > Dear Matt
> > 
> > 
> > 
> > On Wed, Feb 13, 2019 at 9:30 PM Matt Caswell <matt at openssl.org
> > <mailto:matt at openssl.org>> wrote:
> > 
> >     Please see my blog post for an OpenSSL 3.0 and FIPS Update:
> > 
> >     https://www.openssl.org/blog/blog/2019/02/13/FIPS-update/
> > 
> > 
> > After reading the proposed architecture description, I have some questions that
> > are very important for the developers of non-US certified openssl-based products.
> 
> Hi Dmitry,
> 
> Answers inserted.
> 
> > 
> > 1. Will it still be available to implement custom RAND_methods via the new
> > providers API?
> 
> Yes, I expect this to be possible.

This is something I'd like to see explored further.  OpenSSL 3.0 will
target the EVP API primarly, and while we do talk about entropy with
regards to FIPS, I haven't quite grasped if that would be a provider
internal thing or if entropy is supposed to come from "elsewhere".

Since our RAND API is separate from the EVP API, I'm unsure how we
plan on getting custom RAND_methods from providers.

Please note that we can add RAND to the list of provider backed APIs,
and given a foundation that we're currently building, it may even be
quite easy.  However, no one has said explicitly that we would do so.

The other option is, of course, to move the RAND API to EVP somehow,
but that will probably be more challenging.

> > 2. Can we do something with a bunch of hard-linked non-extendable lists of
> > internal NIDs? 
> > For example, providing GOST algorithms always requires a patch to extend 3-5
> > internal lists.
> > If it could be done dynamically, it will be great.
> 
> That's not currently something we've considered, but I agree it
> would be great to fix that. Perhaps you could create a github issue
> identifying the specific areas we should be looking at and then we
> can take a look at the feasibility of fixing it.

Let me address this in a different way...

Are you very attached to those NIDs and them actually being NIDs?  Or
would you be just as happy to have the implementations identified by
name?  You see, providers will offer algorithm implementation by
algorithm name (oh, and properties), not by number.

> > 3. Do you have plans to make some callback structures created by providers? 
> > I mean such structures as SSL key exchange/authentication methods, X.509
> > extensions etc.
> 
> There aren't any plans to do that at the moment. There's nothing in the provider
> design that would prevent us from doing so at some point in the future.

Cheers,
Richard

-- 
Richard Levitte         levitte at openssl.org
OpenSSL Project         http://www.openssl.org/~levitte/