PKCS12 APIs with fips 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

PKCS12 APIs with fips 3.0

Zeke Evans-2

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?

 

Thanks,

Zeke Evans

Micro Focus

Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

OpenSSL - User mailing list
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.

The only exception would be if FIPS allowed implementing PKCS12KDF
using an otherwise unapproved algorithm such as SHA1.  In that
particular case, it would make sense to check if a provider offered
such as PKCS12KDF variant before trying (and failing) to run
provider-independent code that invokes the provider implementation
of a FIPS-unapproved algorithm.
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
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Matt Caswell-2


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.

Matt
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

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

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


Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Dr Paul Dale-2
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.
>
Reply | Threaded
Open this post in threaded view
|

RE: PKCS12 APIs with fips 3.0

Zeke Evans-2
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 <[hidden email]> On Behalf Of Dr Paul Dale
Sent: Tuesday, January 26, 2021 5:22 PM
To: [hidden email]
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.
>
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Dr Paul Dale-2
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 <[hidden email]> On Behalf Of Dr Paul Dale
> Sent: Tuesday, January 26, 2021 5:22 PM
> To: [hidden email]
> 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.
>>
Reply | Threaded
Open this post in threaded view
|

RE: PKCS12 APIs with fips 3.0

Zeke Evans-2
That works.  Thanks!

-----Original Message-----
From: openssl-users <[hidden email]> On Behalf Of Dr Paul Dale
Sent: Tuesday, January 26, 2021 6:01 PM

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

Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

OpenSSL - User mailing list
In reply to this post by Dr Paul Dale-2
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 <[hidden email]> On Behalf Of
>> Dr Paul Dale
>> Sent: Tuesday, January 26, 2021 5:22 PM
>> To: [hidden email]
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Tomas Mraz
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 <[hidden email]> On Behalf
> > > Of
> > > Dr Paul Dale
> > > Sent: Tuesday, January 26, 2021 5:22 PM
> > > To: [hidden email]
> > > 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.]


Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Matt Caswell-2
In reply to this post by OpenSSL - User mailing list


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 <[hidden email]> On Behalf Of
>>> Dr Paul Dale
>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>> To: [hidden email]
>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

OpenSSL - User mailing list
In reply to this post by Tomas Mraz
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 <[hidden email]> On Behalf
>>>> Of
>>>> Dr Paul Dale
>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>> To: [hidden email]
>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Tomas Mraz
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 <[hidden email]> On
> > > > > Behalf
> > > > > Of
> > > > > Dr Paul Dale
> > > > > Sent: Tuesday, January 26, 2021 5:22 PM
> > > > > To: [hidden email]
> > > > > 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.]


Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

OpenSSL - User mailing list
If the context does not limit the use of higher level compositions, then
OpenSSL 3.0 provides no way to satisfy the usual requirement that a
product can be set into "FIPS mode" and not invoke the non-validated
lower level algorithms in the "default" provider.

The usual context is to "sell" (give) products to the US Government or
its contractors that have a "FIPS" box-checking procurement requirement.

On 2021-01-28 10:46, Tomas Mraz wrote:

> 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 <[hidden email]> On
>>>>>> Behalf
>>>>>> Of
>>>>>> Dr Paul Dale
>>>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>>>> To: [hidden email]
>>>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Tomas Mraz
This is a purely hypothetical context. Besides, as I said below - the
PKCS12KDF should not be used with modern PKCS12 files. Because it can
be used only with obsolete encryption algorithms anyway - the best one
being 3DES for the encryption and SHA1 for the KDF.

Tomas

On Thu, 2021-01-28 at 11:08 +0100, Jakob Bohm via openssl-users wrote:

> If the context does not limit the use of higher level compositions,
> then
> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
> product can be set into "FIPS mode" and not invoke the non-validated
> lower level algorithms in the "default" provider.
>
> The usual context is to "sell" (give) products to the US Government
> or
> its contractors that have a "FIPS" box-checking procurement
> requirement.
>
> On 2021-01-28 10:46, Tomas Mraz wrote:
> > 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

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


Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

OpenSSL - User mailing list
If that is a hypothetical context, what context is the official design
goal of the OpenSSL Foundation for their validation effort?

On 2021-01-28 11:26, Tomas Mraz wrote:

> This is a purely hypothetical context. Besides, as I said below - the
> PKCS12KDF should not be used with modern PKCS12 files. Because it can
> be used only with obsolete encryption algorithms anyway - the best one
> being 3DES for the encryption and SHA1 for the KDF.
>
> Tomas
>
> On Thu, 2021-01-28 at 11:08 +0100, Jakob Bohm via openssl-users wrote:
>> If the context does not limit the use of higher level compositions,
>> then
>> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
>> product can be set into "FIPS mode" and not invoke the non-validated
>> lower level algorithms in the "default" provider.
>>
>> The usual context is to "sell" (give) products to the US Government
>> or
>> its contractors that have a "FIPS" box-checking procurement
>> requirement.
>>
>> On 2021-01-28 10:46, Tomas Mraz wrote:
>>> 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
>



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
Reply | Threaded
Open this post in threaded view
|

Re: PKCS12 APIs with fips 3.0

Dr Paul Dale-2
In reply to this post by OpenSSL - User mailing list
Of course OpenSSL 3.0 will support a strict FIPS mode and this will be
the recommended set up.  By setting the default query to "fips=yes" or
(better) setting up a library context that has no non-FIPS cryptographic
implementations and you are in a strictly compliant FIPS mode.

If you want to use the PKCS #12 KDF, then you want something that
*cannot* currently be FIPS validated --> you are not running in strict
FIPS mode and need a solution that allows FIPS validated cryptographic
implementations to be bypassed.


Pauli

On 28/1/21 8:08 pm, Jakob Bohm via openssl-users wrote:

> If the context does not limit the use of higher level compositions, then
> OpenSSL 3.0 provides no way to satisfy the usual requirement that a
> product can be set into "FIPS mode" and not invoke the non-validated
> lower level algorithms in the "default" provider.
>
> The usual context is to "sell" (give) products to the US Government or
> its contractors that have a "FIPS" box-checking procurement requirement.
>
> On 2021-01-28 10:46, Tomas Mraz wrote:
>> 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 <[hidden email]> On
>>>>>>> Behalf
>>>>>>> Of
>>>>>>> Dr Paul Dale
>>>>>>> Sent: Tuesday, January 26, 2021 5:22 PM
>>>>>>> To: [hidden email]
>>>>>>> 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