You could set the default property query to "?fips=yes". This will
prefer FIPS algorithms over any others but will not prevent other
algorithms from being fetched.
Pauli
On 27/1/21 10:47 am, Zeke Evans wrote:
I understand that PKCS12 cannot be implemented in the fips provider but I'm looking for a suitable workaround, particularly something that is close to the same behavior as 1.0.2 with the fips 2.0 module.
In my case, the default provider is loaded but I am calling EVP_set_default_properties(NULL, "fips=yes"). I can wrap calls to the PKCS12 APIs and momentarily allow non-fips algorithms (ie: "fips=no" or "provider=default") but that prevents the PKCS12 implementation from using the crypto implementations in the fips provider. Is there a property string or some other way to allow PKCS12KDF in the default provider as well as the crypto methods in the fips provider? I have tried "provider=default,fips=yes" but that doesn't seem to work.
Using the default provider is probably a reasonable workaround for reading in PKCS12 files in order to maintain backwards compatibility. Is there a recommended method going forward that would allow reading and writing to a key store while only using the fips provider?
Thanks,
Zeke Evans
Micro Focus
-----Original Message-----
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Dr Paul Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: openssl-users@xxxxxxxxxxx
Subject: Re: PKCS12 APIs with fips 3.0
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.
