FIPS compliance efforts in Fedora and RHEL

[Dmitry Belyavskiy]

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

-- 
Dmitry Belyavskiy