On Wed, 27 Feb 2019 21:55:29 +0100, Jakob Bohm via openssl-users wrote: > > On 27/02/2019 20:59, Salz, Rich via openssl-users wrote: > > If you change a single line of code or do not build it EXACTLY as documented, you cannot claim to use the OpenSSL validation. > > > > I believe the context here is one I also mentioned in my comment on > the 3.0 draft spec: > > - OpenSSL FIPS Module provides FIPS validated software implementations of > all/most of the permitted algorithms. > - Engine provides FIPS validated (hardware?) implementations of one or > more implementations, under a separate FIPS validation, perhaps done > at the hardware level. > - FIPS-capable OpenSSL (outside the FIPS boundary) is somehow made to use > both FIPS validated modules depending on various conditions (such as > algorithm availability). FIPS-capable OpenSSL can be changed without > breaking the FIPS validation of the modules. > - Overall application claims FIPS compliance as all crypto is done by > FIPS validated modules. Side note: "FIPS-capable OpenSSL" isn't quite right. Basically, if libcrypto is capable of loading a dynamically loadable module, it's "FIPS-capable", since it can load the FIPS provider module. I see no reason why libcrypto should be able to load two FIPS-validated modules (*) and use them both, all depending on what algorithms and properties are desired (apart from the "fips" property). However, I've come to understand that those two modules must not be made to cooperate, i.e. for a signing operation using sha256WithRSAEncryption, it's not permitted for one module to do the sha256 part and the other module to do the RSA calculations. Cheers, Richard ----- (*) an engine module is also a module... all that actually makes it an OpenSSL engine is two entry points, "bind_engine" and "v_check". -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/
