3.0 FIPS related questions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

3.0 FIPS related questions

Pete
Hello,

I have two questions regarding support for FIPS in 3.0.  We're currently working on early planning for our migration to OpenSSL 3.0 and we're
trying to size the effort for our team.  We're also beginning to put together contingency plans in the event that dates on either side change
dramatically.  I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly.

Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL
based FOM.  We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the
test lab on this slightly modified FOM.  We had the impression that there are other groups that do the same.  An example of additional
functionality, especially for the 3.0 FOM, might be something like the SSH KDF.  If this KDF were to not be included in the 3.0 FOM and we
needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through
a complete FIPS validation.  If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we
could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this
supplemental FOM active at the same time in our solution.  So the question is, will the OpenSSL 3.0 design allow for more than one active
FIPS provider?

I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an
explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.  If it's at all
possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.  On the other hand, am I completely missing some
fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it
used to be?

The second question is somewhat related.  Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?

Thanks,
Pete

Reply | Threaded
Open this post in threaded view
|

Re: 3.0 FIPS related questions

Matt Caswell-2


On 24/03/2020 14:06, Pete wrote:

> Hello,
>
> I have two questions regarding support for FIPS in 3.0.  We're currently working on early planning for our migration to OpenSSL 3.0 and we're
> trying to size the effort for our team.  We're also beginning to put together contingency plans in the event that dates on either side change
> dramatically.  I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly.
>
> Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL
> based FOM.  We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the
> test lab on this slightly modified FOM.  We had the impression that there are other groups that do the same.  An example of additional
> functionality, especially for the 3.0 FOM, might be something like the SSH KDF.  If this KDF were to not be included in the 3.0 FOM and we
> needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through
> a complete FIPS validation.  If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we
> could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this
> supplemental FOM active at the same time in our solution.  So the question is, will the OpenSSL 3.0 design allow for more than one active
> FIPS provider?

Yes, this is possible. As far as end applications are concerned FIPS
validated algorithms must be "fetched". Applications can either do this
explicitly or implicitly. If done explicitly then you must specify the
name of the algorithm you wish to use, and a property query string. If
done implicitly then the same thing happens inside libcrypto. The name
of the algorithm is inferred, and a default property query string is
used (which can be set through a config file).

All algorithms that exist within the FIPS provider use the property
string "fips=yes". So if you only want to use FIPS validated algorithms
then you just set that query string to be the default - or specify that
query string explicitly if doing explicit fetching.

There is nothing to stop you from having a second FIPS provider loaded
with different algorithms in it. As long as you specify all the
algorithms in that provider to have "fips=yes" against them, then it
will appear the same as any other FIPS validated algorithm to an end
application.

Another way end applications can arrange things is to forget about
property strings and only ever have the FIPS provider(s) loaded (ie. do
not load the default provider). This means all algorithms will come from
the FIPS providers. Again there is nothing to stop you from having
multiple of these.

>
> I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an
> explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.  If it's at all
> possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.  On the other hand, am I completely missing some
> fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it
> used to be?
>
> The second question is somewhat related.  Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?

We are going through 140-2.

Matt

Reply | Threaded
Open this post in threaded view
|

Re: 3.0 FIPS related questions

Pete
Hi Matt,

Thanks so much for the quick and thorough response.  I had caught bits
and pieces of the algorithm selection process while going through the
design doc but apparently didn't catch just how flexible it really is. 

As for the 140 level of testing, that's just what we expected.

Thanks again,
Pete

On 3/24/20 10:19 AM, Matt Caswell wrote:

>
> On 24/03/2020 14:06, Pete wrote:
>> Hello,
>>
>> I have two questions regarding support for FIPS in 3.0.  We're currently working on early planning for our migration to OpenSSL 3.0 and we're
>> trying to size the effort for our team.  We're also beginning to put together contingency plans in the event that dates on either side change
>> dramatically.  I suspect I already know the answers to these questions, but I wanted to ask just to be sure so that we plan correctly.
>>
>> Over the years we have had requirements to include additional functionality within our FIPS boundary beyond what was in the OpenSSL
>> based FOM.  We would start with the existing OpenSSL FOM, add in the additional functionality, and then go through a full validation with the
>> test lab on this slightly modified FOM.  We had the impression that there are other groups that do the same.  An example of additional
>> functionality, especially for the 3.0 FOM, might be something like the SSH KDF.  If this KDF were to not be included in the 3.0 FOM and we
>> needed a FIPS validated version of it in our solutions, we would need to move this into the FIPS provider and then take this altered FOM through
>> a complete FIPS validation.  If however, we were to create a 3rd party provider that only contains this supplemental FIPS functionality, we
>> could go through an abbreviated FIPS validation of just that functionality and then have both the OpenSSL 3.0 FOM and this
>> supplemental FOM active at the sa,me time in our solution.  So the question is, will the OpenSSL 3.0 design allow for more than one active
>> FIPS provider?
> Yes, this is possible. As far as end applications are concerned FIPS
> validated algorithms must be "fetched". Applications can either do this
> explicitly or implicitly. If done explicitly then you must specify the
> name of the algorithm you wish to use, and a property query string. If
> done implicitly then the same thing happens inside libcrypto. The name
> of the algorithm is inferred, and a default property query string is
> used (which can be set through a config file).
>
> All algorithms that exist within the FIPS provider use the property
> string "fips=yes". So if you only want to use FIPS validated algorithms
> then you just set that query string to be the default - or specify that
> query string explicitly if doing explicit fetching.
>
> There is nothing to stop you from having a second FIPS provider loaded
> with different algorithms in it. As long as you specify all the
> algorithms in that provider to have "fips=yes" against them, then it
> will appear the same as any other FIPS validated algorithm to an end
> application.
>
> Another way end applications can arrange things is to forget about
> property strings and only ever have the FIPS provider(s) loaded (ie. do
> not load the default provider). This means all algorithms will come from
> the FIPS providers. Again there is nothing to stop you from having
> multiple of these.
>
>> I've made a pass through the 3.0 design specification looking specifically at FIPS provider related content but did not see an
>> explicit statement that there can only be one FIPS provider, although, I suspect this is the case and wanted to confirm this.  If it's at all
>> possible to have two active FIPS provider, it could make subsequent FIPS validations simpler.  On the other hand, am I completely missing some
>> fundamental aspect of FIPS provider functionality in 3.0 and this need to add additional support into the FOM will not be as involved as it
>> used to be?
>>
>> The second question is somewhat related.  Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?
> We are going through 140-2.
>
> Matt
>

Reply | Threaded
Open this post in threaded view
|

Re: 3.0 FIPS related questions

OpenSSL - User mailing list
In reply to this post by Matt Caswell-2
 
>    > The second question is somewhat related.  Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?
   
>    We are going through 140-2.
 
Has the list of validated platforms been made public yet?

For people using a different platform, will they still be able to claim "vendor affirmed" if they follow particular build steps?

Reply | Threaded
Open this post in threaded view
|

Re: 3.0 FIPS related questions

Matt Caswell-2


On 24/03/2020 15:02, Salz, Rich wrote:
>  
>>    > The second question is somewhat related.  Has there been a decision yet whether the FOM 3.0 will go through a 140-2 or a 140-3 validation?
>    
>>    We are going through 140-2.
>  
> Has the list of validated platforms been made public yet?

No, not yet. Although I don't see a great reason why they shouldn't be.
I'll raise it and check everyone is happy to do so.

>
> For people using a different platform, will they still be able to claim "vendor affirmed" if they follow particular build steps?
>

Yes, we believe this will remain as per the previous module. The build
process will be different, but the ability to vendor affirm other
platforms should remain.

Matt