> I always understood "FIPS-capable OpenSSL" to refer specifically to an
OpenSSL compiled with the options to incorporate the FIPS canister
module, not just any OpenSSL build that might be used in FIPS compliant
applications (as that would be any OpenSSL at all).
Yes, that is historically correct. I don't believe the project uses the term "FIPS-capable OpenSSL" any more. Instead, the design and such talk about a FIPS module which OpenSSL can use.
> 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).
Richard made a typo here. He means there is no reason why libcrypto should NOT be able to load two modules.
> 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.
I believe Richard is wrong here. Or at least his text could be misleading. If the EVP API does the digesting with one module and then calls another module to do the RSA signing, that is okay. If the "digest and sign" module calls out to another module *itself* that is probably not okay.
