PKCS12 APIs with fips 3.0

[Jakob Bohm]

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-bounces at openssl.org> On Behalf Of 
>> Dr Paul Dale
>> Sent: Tuesday, January 26, 2021 5:22 PM
>> To: openssl-users at 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
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded