FIPS compliance efforts in Fedora and RHEL

[Dmitry Belyavskiy]

Dear Damien,



On Wed, Apr 19, 2023 at 10:01 AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote:
>
> Dear Damien,
>
> On Wed, Apr 19, 2023 at 9:55 AM Damien Miller <djm at mindrot.org> wrote:
> >
> > On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote:
> >
> > > > While I'm sure this is good for RHEL/rawhide users who care about FIPS,
> > > > Portable OpenSSH won't be able to merge this. We explictly aim to support
> > > > LibreSSL's libcrypto as well as openssl-1.1.x and neither supports the
> > > > OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that
> > > > I'd describe as "best effort").
> > > >
> > > > If this changes we can look again.
> > >
> > > Yes, we understand and respect your choice.
> > > Would it be acceptable in any form being wrapped in necessary #ifdefs ?
> >
> > No, I think it would be too intrusive.
> >
> > IMO if we have to support both the new API and the libressl/1.1.1 API
> > then the only likely acceptable way would be to reimplement the new
> > API using the old, similar to what we did when moving to the OpenSSL
> > 1.1.x opaque structs while still supporting the 1.0.x API.
> >
> > I have no idea whether this is even possible, and we wouldn't have the
> > luxury of being able to use OpenSSL code to do it (as we did last time)
> > as the license has changed to one that we don't want to accept in the
> > OpenSSH codebase.
>
> I think it's doable if libressl has 1.1.1-style EVP API. It is
> possible to assign RSA/EC/DH to EVP_PKEY object and use EVP API
> afterwards in 1.1.1 and use the OSSL_PARAM_BLD for 3.0

Will the patch providing compat layer in style
=====
EVP_PKEY *EVP_PKEY_from_DH
{
#ifdef LIBRESSL
return EVP_PKEY_set0_DH
#else
#if OPENSSL_30
... PARAM_BLD..
#endif
#endif
}
=====
and making the crypto operations using EVP API in main files be acceptable?

-- 
Dmitry Belyavskiy