PKCS12 APIs with fips 3.0

[Dr Paul Dale]

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.
>>