Anthony Scarpino wrote: > Krishna Yenduri wrote: >> Hai-May Chao wrote: >> >> The proposal looks good. >>> ... >>> >>> c. When disable/enable fips command is issued from cryptoadm, >>> we make sure that the following places are sync'ed: >>> pkcs11.conf, kcf.conf and the global variable in kernel >>> indicating >>> the FIPS status. >>> >> >> What happens during boot? Do we look at both pkcs11.conf and kcf.conf >> and then issue a "cryptoadm enable fips", if needed? >> >> What happens if for some reason, pkcs11.conf and kcf.conf are >> in disagreement (say system panicked before kcf.conf could be updated)? > > Yes, I noticed that too.. one configuration location would be better, > unless there is some functionality that I'm missing by having it > separate.. >
Agreed - We can keep it in a single place kcf.conf that should serve its purpose. That will eliminate the problem with two being out of sync. >>> >>> c. Keeping pkcs11_kernel enabled >>> >>> We don't disable pkcs11_kernel as pkcs11_kernel and KCF are >>> inside >>> the crypto boundary. It is what is plugged into KCF that is >>> the issue, >>> such as ncp and n2cp that should be disabled, but not >>> pkcs11_kernel. >>> >> >> Do we document that the admin should disable ncp and n2cp before doing >> "cryptoadm enable fips" OR do we do it as part of the "cryptoadm >> enable fips" >> processing? > > I would think documentation would be the right thing.. We'll never > know if it's fips approved hardware or not.. An idea would be to have > a message displayed after the 'cryptoadm enable fips' command to call > out the providers: > > # cryptoadm enable fips > The following may not be FIPS certified hardware. Please verify if > they are and that they are in FIPS mode: > ncp/0 > mca/0 > # > > the same could be done with userland providers that are not softtoken. > > > I also think documentation is the right approach. Calling out the providers sounds like a good idea. Thanks for your review! Hai-May
