On 28/01/2021 08:26, 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. In 3.0 all crypto algorithms are moved to providers. Higher level features such as CMS and TLS etc remain in libcrypto/libssl. Applications can load the providers that they want to use for any given situation. To simulate the way that 1.0.x worked in FIPS mode then they can choose to *only* load the FIPS provider which will guarantee that no non FIPS-validated crypto can be used. Alternatively they can have both FIPS and non-FIPS crypto providers loaded and available at the same time and swap between them as required for the context. More details of how this works are on the 3.0 wiki page here: https://wiki.openssl.org/index.php/OpenSSL_3.0 In particular section 7 of the above page discusses the various options you have for using FIPS validated crypto. Matt > > 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-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. >>>> > Enjoy > > Jakob
