[openssl-project] OpenSSL 3.0 and FIPS Update

[Dmitry Belyavsky]

Dear Richard,

On Sat, Feb 23, 2019 at 8:47 AM Richard Levitte <levitte at openssl.org> wrote:

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

I do not think it is really necessary to move RAND to EVP.
Current architecture suits our requirements, but if the possibility to
overwrite
the RAND_METHOD is removed, it will cause problems for us.


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

The command
grep -ril gost . | grep -v objects
in the crypto/ folder enlists the following files:

./cms/cms_sd.c
./asn1/asn_mime.c
./x509/x509type.c
./pkcs12/p12_mutl.c
./evp/evp_pbe.c
./pkcs7/pk7_smime.c

Namely the functions CMS_add_standard_smimecap, PKCS7_sign_add_signer,
asn1_write_micalg, X509_certificate_type and array builtin_pbe[] refer to
gost-related NIDs.

The pkcs12_gen_mac function has a gost-specific processing.
It was much more simple to add gost-specific processing here than to add
a callback everywhere, though it breaks encapsulation I dream about.

Also, we have some patches adding Russian-specific X.509 extensions,
and I think for now it's better to register the necessary NIDs and provide
pull requests to add their processing.

The situation in libssl is much more difficult, because of more monolithic
architecture there.


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

-- 
SY, Dmitry Belyavsky
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190223/3ae19d4c/attachment.html>