On 27/02/2019 22:20, Richard Levitte wrote: >> 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. > > 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. > > Ref: https://www.openssl.org/docs/OpenSSL300Design.html#example-dynamic-views-of-algorithm-selection Also from the design document: "Once in a FIPS module provided algorithm, we must remain within the FIPS module for any other cryptographic operations. It would be allowed by the FIPS rules for one FIPS module to use another FIPS module. However, for the purposes of the 3.0 design we are making the simplifying assumption that we will not allow this. For example an EVP_DigestSign* implementation uses both a signing algorithm and digest algorithm. We will not allow one of those algorithms to come from the FIPS module, and one to come from some other provider." Note the the text Richard quotes above talks about *the* FIPS module - i.e. it is in specific reference to our FIPS module. It is not making a general statement about the FIPS rules. In general, my understanding is that it is ok for one FIPS module to do signing and another one to do digesting. However we are making the simplifying assumption that in *our* FIPS module we will not allow this. Matt
