RE: fips mode and key management

2020-01-21 Thread Dr. Matthias St. Pierre

> >distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
> more fitting than FIPS_MODE?
> 
> 
> Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use 
> OPENSSL_BUILDING_OPENSSL ...

OPENSSL_BUILDING_OPENSSL is really a remarkably long name.  I hope this does 
not blow up any commandline
length limits . How about using OSSL_LIBRARY library instead? This would fit 
nicely to OSSL_FIPS_PROVIDER:

#ifdef OSSL_LIBRARY
...
#endif

#ifdef OSSL_FIPS_PROVIDER
...
#endif

> There's no reason to use OSSL for internal macros.

But it avoids unnecessary name clashes with system headers. Just today, I saw 
this collision with Windows headers:

include/openssl/types.h:74:#  undef OCSP_REQUEST
include/openssl/types.h:75:#  undef OCSP_RESPONSE

(Yes I know, Window headers are really polluting the global namespace).




Re: fips mode and key management

2020-01-21 Thread Salz, Rich
>distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?
  

Or perhaps OPENSSL_BUILDING_FIPS, since a couple of PR's already have and use 
OPENSSL_BUILDING_OPENSSL ...

There's no reason to use OSSL for internal macros.





Re: fips mode and key management

2020-01-21 Thread Tomas Mraz
I can only add +1 to what Matthias suggests. Although I know the
meaning of the FIPS_MODE define, for a newcomer it is obviously not
clear what the define really means.

Tomas

On Tue, 2020-01-21 at 13:31 +0100, Matthias St. Pierre wrote:
> On 21.01.20 10:36, Richard Levitte wrote:
> > I think that the misunderstanding lies in when FIPS_MODE is
> > defined.
> 
> Reading this sentence it occurred to me that the misunderstanding
> comes from
> the fact that the define is indeed misnamed. The term "FIPS mode" is
> a relict
> from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable
> FIPS mode
> *at runtime*.
> 
> (Note that the *compile time* option to include the FOM was called
> OPENSSL_FIPS,
> not FIPS_MODE. So the misleading name must have crept in only
> recently.)
> 
> > It's defined when the FIPS provider module is being built, never
> > otherwise.
> 
> Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are
> partially built from
> the same source files, which is the reason why we need a build time
> constant to
> distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would
> be
> more fitting than FIPS_MODE?
> 
> 
>  #ifdef OSSL_FIPS_PROVIDER
>  ...
>  #endif
> 
> 
> Matthias
> 
> 
> P.S: Even though it is an internal define, it should have an OSSL_
> prefix IMHO.
> P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER,
> OSSL_LEGACY_PROVIDER, ...
> 
-- 
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.]




Re: fips mode and key management

2020-01-21 Thread Matthias St. Pierre



BTW: the following build time constant with the remarkably long name seems to 
be intended for
a related purpose,  but it is currently completely unused?

    Configurations/00-base-templates.conf:  lib_defines => [ 
'OPENSSL_BUILDING_OPENSSL' ],




Re: fips mode and key management

2020-01-21 Thread Matthias St. Pierre

On 21.01.20 10:36, Richard Levitte wrote:

I think that the misunderstanding lies in when FIPS_MODE is defined.


Reading this sentence it occurred to me that the misunderstanding comes from
the fact that the define is indeed misnamed. The term "FIPS mode" is a relict
from FIPS 2.0, where the OpenSSL 1.0.x library had an API to enable FIPS mode
*at runtime*.

(Note that the *compile time* option to include the FOM was called OPENSSL_FIPS,
not FIPS_MODE. So the misleading name must have crept in only recently.)


It's defined when the FIPS provider module is being built, never otherwise.


Exactly, in OpenSSL 3.0 the DEFAULT and the FIPS provider are partially built 
from
the same source files, which is the reason why we need a build time constant to
distinguish those two cases. Maybe the name OSSL_FIPS_PROVIDER would be
more fitting than FIPS_MODE?


    #ifdef OSSL_FIPS_PROVIDER
    ...
    #endif


Matthias


P.S: Even though it is an internal define, it should have an OSSL_ prefix IMHO.
P.P.S: Optionally, one could also #define an OSSL_DEFAULT_PROVIDER, 
OSSL_LEGACY_PROVIDER, ...



Re: fips mode and key management

2020-01-21 Thread Richard Levitte
This doesn't affect applications.  Our FIPS module holds its own
keys, but reuse the same structures as libcrypto to hold them
internally, and *there*, the EX_DATA field is irrelevant.
Applications will never get that far in.  The EX_DATA added by the
application is still valid.

I think that the misunderstanding lies in when FIPS_MODE is defined.
It's defined when the FIPS provider module is being built, never
otherwise.

Cheers,
Richard

On Sat, 18 Jan 2020 12:19:25 +0100,
Roumen Petrov wrote:
> 
> Hello,
> 
> Recently I note that when build is in FIPS_MODE some functionality is
> lost. For instance RSA_{g|s}et_ex_data is not available.
> 
> Reading the code I expect that in FIPS mode use of external keys is
> forbidden.
> Remark: ex_data is used to store reference information for external keys.
> 
> Please confirm that in FIPS mode we could use external keys?
> 
> 
> Regards
> Roumen Petrov
> 
> P.S. If is not allowed this regression to previous FIPS
> releases(validations).
> Neither OpenSSL nor Red Hat nor Solaris FIPS validation forbid use of
> "external" keys.
> 
-- 
Richard Levitte levi...@openssl.org
OpenSSL Project http://www.openssl.org/~levitte/