The fipsinstall program runs the platform tests. I.e. you need to run fipsinstall on the device at some point.
> Or are you suggesting that the presence of a standalone tool might influence > the contents of such a security policy? Yes. Well maybe. I’ll posit the possibility at the next planning meeting. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Jul 2020, at 9:51 am, Thomas Dwyer III <tom...@tomiii.com> wrote: > > On Mon, Jul 27, 2020 at 3:39 PM Dr Paul Dale <paul.d...@oracle.com > <mailto:paul.d...@oracle.com>> wrote: > These are questions better asked of a FIPS lab since they are the experts and > we are not. > > > > That is a fair response. > > > I expect that your alternative installation process’s validity will depend on > the security policy and what it says needs to be done. This hasn’t been > written yet so there is no answer at this point. > > Skipping the self tests is definitely not permitted. The full suite of self > tests *must* be run before the module can be used. > > > > Oops, I didn't mean to suggest skipping the self-tests. I was talking about > the callback that fipsinstall currently uses to display results and/or inject > faults in the self-tests. I don't think I need that. As long as > OSSL_PROVIDER_load() succeeds it seems safe (?) to assume that all the > self-tests passed at some point. > > > > You question prompts the possibility of making fipsinstall a standalone > executable, this is something we could look into if we get time. I expect > we’d look favourably on a pull request that allowed either or both options. > > > > This is encouraging. However, since there is no draft security policy written > yet would this be premature? Or are you suggesting that the presence of a > standalone tool might influence the contents of such a security policy? > > > Thanks, > Tom.III > > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 28 Jul 2020, at 6:19 am, Thomas Dwyer III <tom...@tomiii.com >> <mailto:tom...@tomiii.com>> wrote: >> >> Hi all, >> >> I'm replacing OpenSSL 1.0.2 with OpenSSL 3.0 in an embedded environment with >> very limited flash space. We need and use libcrypto and libssl but we have >> no need for the openssl binary. To date it was never necessary to ship this >> utility in our product. Now with OpenSSL 3.0 it appears the only way to get >> FIPS support is to run "openssl fipsinstall ..." to create a FIPS config >> file to be included by the main config file. However, at nearly 1MB in size >> this binary is prohibitively large. >> >> I am able to reproduce the output of "openssl fipsinstall ..." with a >> (considerably smaller) standalone tool that links with libcrypto and >> generates HMAC-SHA256 (using FIPS_KEY_STRING from fipskey.h) but I'm unclear >> on what the actual FIPS requirements are for this. Would I still be >> considered FIPS compliant if I use my own standalone tool instead of the >> openssl binary to generate the FIPS config? I presume I don't need to bother >> with the self-test callback and that it only matters whether or not >> OSSL_PROVIDER_load(NULL, "fips") succeeds? >> >> >> Thanks, >> Tom.III >> >
