There is unfortunately no simple straightforward answer to this
question. It really depends on the context.
Anyway OpenSSL 3.0 gives you all the flexibility needed.
Tomas
On Thu, 2021-01-28 at 10:24 +0100, Jakob Bohm via openssl-users wrote:
> Does FIPS 140 or the related legal requirements limit the use of
> higher
> level compositions such as PKCS12KDF, when using only validated
> cryptography for the underlying operations?
>
> On 2021-01-28 09:36, Tomas Mraz wrote:
> > I do not get how you came to this conclusion. The "true" FIPS mode
> > can
> > be easily achieved with OpenSSL 3.0 - either by loading just the
> > fips
> > and base provider, or by loading both default and fips providers
> > but
> > using the "fips=yes" default property (without the "?").
> >
> > The PKCS12KDF does not work because it is not an FIPS approved KDF
> > algorithm so it cannot really work in the "true" FIPS mode. But IMO
> > this does not mean that PKCS12 keys do not work at all - if you use
> > right (more modern) algoritm based on PBKDF2 to do the password
> > based
> > key derivation, they should work.
> >
> > That in 1.0.x the PKCS12 worked with the FIPS module with legacy
> > algorithms it only shows that the "true" FIPS mode was not as
> > "true" as
> > you might think. There were some crypto algorithms like the KDFs
> > outside of the FIPS module boundary.
> >
> > Tomas Mraz
> >
> > On Thu, 2021-01-28 at 09:26 +0100, Jakob Bohm via openssl-users
> > wrote:
> > > Does that mean that OpenSSL 3.0 will not have a true "FIPS mode"
> > > where
> > > all the non-FIPS algorithms are disabled, but the FIPS-
> > > independent
> > > schemes/protocols in the "default" provider remains available?
> > >
> > > Remember that in other software systems, such as OpenSSL 1.0.x
> > > and
> > > MS
> > > CryptoAPI, FIPS mode causes all non-validated algorithms to fail
> > > hard,
> > > so all higher level operations are guaranteed to use only FIPS-
> > > validated
> > > crypto.
> > >
> > > On 2021-01-27 02:01, Dr Paul Dale wrote:
> > > > 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-boun...@openssl.org> On
> > > > > Behalf
> > > > > Of
> > > > > Dr Paul Dale
> > > > > Sent: Tuesday, January 26, 2021 5:22 PM
> > > > > To: openssl-users@openssl.org
> > > > > 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.
> > > > > >
>
>
>
> Enjoy
>
> Jakob
--
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.]
