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
