On Thu, 28 Feb 2019 00:17:13 +0100, Salz, Rich wrote: > > > Huh? From the design document, section "Example dynamic views of > algorithm selection", after the second diagram: > > An EVP_DigestSign* operation is more complicated because it > involves two algorithms: a signing algorithm, and a digest > algorithm. In general those two algorithms may come from different > providers or the same one. In the case of the FIPS module the > algorithms must both come from the same FIPS module provider. The > operation will fail if an attempt is made to do otherwise. > > There are two options. First, the application does the digest and > sign as two separate things. My memory is a foggy surrounding that scenario, so I might be wrong, but I think it was argued that this was invalid use from a FIPS perspective. Now, we can't actually stop any application from doing this, sure! But... > Second, the provider implementing digestSign has to be validated to > use the other FIPS module. Yes, and this is, as far as I remember, a "combined FIPS module" (I don't remember the exact terminology, sorry) which is supposed to be validated together and present itself to libcrypto as one provider, not two. However, what you wrote earlier was this: > If the EVP API does the digesting with one module and then calls > another module to do the RSA signing, that is okay. That suggests to me that libcrypto could "magically" combine two different FIPS providers, which would be none of the two options mentioned above. Cheers, Richard -- Richard Levitte levitte@xxxxxxxxxxx OpenSSL Project http://www.openssl.org/~levitte/
