On Tue, 2021-01-26 at 11:45 +0000, Matt Caswell wrote:
>
> On 26/01/2021 11:05, Jakob Bohm via openssl-users wrote:
> > On 2021-01-25 17:53, Zeke Evans wrote:
> > > Hi,
> > >
> > >
> > >
> > > Many of the PKCS12 APIs (ie: PKCS12_create, PKCS12_parse,
> > > PKCS12_verify_mac) do not work in OpenSSL 3.0 when using the fips
> > > provider. It looks like that is because they try to load
> > > PKCS12KDF
> > > which is not implemented in the fips provider. These were all
> > > working
> > > in 1.0.2 with the fips 2.0 module. Will they be supported in 3.0
> > > with
> > > fips? If not, is there a way for applications running in fips
> > > approved mode to support the same functionality and use existing
> > > stores/files that contain PKCS12 objects?
> > >
> > >
> > >
> > This is an even larger issue: Is OpenSSL 3.x so badly designed
> > that the "providers" need to separately implement every standard
> > or non-standard combination of algorithm invocations?
> >
> > In a properly abstracted design PKCS12KDF would be implemented by
> > invoking general EVP functions for underlying algorithms, which
> > would in turn invoke the provider versions of those algorithms.
>
> This is exactly the way it works. The implementation of PKCS12KDF
> fetches the underlying digest algorithm using whatever providers it
> has
> available. So, for example, if the PKCS12KDF implementation needs to
> use
> SHA256, then it will fetch an available implementation for it - and
> that
> implementation may come from the FIPS provider (or any other
> provider).
>
> However, in 3.0, KDFs are themselves fetchable cryptographic
> algorithms
> implemented by providers. The FIPS module implements a set of KDFs -
> but
> PKCS12KDF is not one of them. Its only available from the default
> provider.
>
> So, the summary is, while you can set things up so that all your
> crypto,
> including any digests used by the PKCS12KDF, all come from the FIPS
> provider, there is no getting away from the fact that you still need
> to
> have the default provider loaded in order to have an implementation
> of
> the PKCS12KDF itself - which will obviously be outside the module
> boundary.
>
> There aren't any current plans to bring the implementation of
> PKCS12KDF
> inside the FIPS module. I don't know whether that is feasible or not.
IMO PKCS12KDF should not be in the FIPS module as this is not a FIPS
approved KDF algorithm. Besides that KDF should not IMO be needed for
"modern" PKCS12 files. I need to test that though.
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
