Should FIPS_mode() and FIPS_mode_set() be updated, deprecated, or completely removed..

[SHANE LONTIS]

FIPS_mode() and FIPS_mode_set() are functions that were used by the old FOM.

In OpenSSL_111 they were stripped down to do almost nothing
i.e:-

int FIPS_mode(void)      
{      
    /* This version of the library does not support FIPS mode. */      
    return 0;      
}

int FIPS_mode_set(int on)      
{
if (r == 0)      
    return 1;    

CRYPTOerr(0, CRYPTO_R_FIPS_MODE_NOT_SUPPORTED); 
return 0;      
}

The original plan for these API’s is listed in the design document for 3.0
i.e- the set would - set the global property and then do a fetch of a particular algorithm (this is problematic in itself since the algorithm may not exist for a 3rd party fips provider which could just implement a single algorithm).
And FIPS_mode() would just return true if the global property for fips was set.

This got some pushback and after discussion with a few other otc members - it was decided that the functions should be deprecated since it would be confusing to a user because there are multiple library contexts allowed each with their own fips property that can be changed at
any time.

This is done in https://github.com/openssl/openssl/pull/11075 <https://github.com/openssl/openssl/pull/11075> and there is a related discussion in the comments.

This PR has also been rejected the deprecation and discusses
- FIPS_mode_set() function could be completely removed.
- FIPS_mode() - query using the default library context OR completely remove.

I have no issue with both functions being deleted as they no longer really mean the same thing as they did before.
Each library context has its own default properties - so querying FIPS_mode() could only return what the default library context’s fips properties are - it doesnt mean every library context is in fips mode, or even that the fips module is loaded. 
If the functions are removed then it may require a OMC vote since this could be viewed as a breaking change..

Does anyone have any thoughts on this?

Regards
Shane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-project/attachments/20200304/b9aa0184/attachment.html>