PKCS12 APIs with fips 3.0

[Dr Paul Dale]

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