I'm not even sure that NIST can validate the PKCS#12 KDF.
If it can't be validated, it doesn't belong in the FIPS provider.
Pauli
On 26/1/21 10:48 pm, Tomas Mraz wrote:
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.
