Huie-Ying Lee wrote: > On 06/16/09 02:30, Darren J Moffat wrote: >> Scott Rotondo wrote: >>>>> >>>>> 4.3 Interfaces: >>>>> >>>>> The following new options are added to cryptoadm(1M) sub-commands >>>>> cryptoadm list fips-140 >>>>> cryptoadm enable fips-140 >>>>> cryptoadm disable fips-140 >>> >>> Very minor issue: People often refer informally to "FIPS mode" rather >>> than the more cumbersome FIPS 140 or FIPS 140-2. Unless you expect >>> other FIPS standards to apply to the crypto framework, maybe you >>> could save users a little typing: >> >> There are other FIPS standards, in particular those that include the >> definitions of particular algorithms or PRNG systems. >> >>> cryptoadm list fips >>> cryptoadm enable fips >>> cryptoadm disable fips >> >> That is what we had originally and I suggested to the team to change >> it to fips-140 because there are lots and lots of FIPS standards and >> this change to cryptoadm only deals with FIPS 140 not 186 or 86 ... So >> having just "fips" is wrong. >> > How about making it more flexible as following: > > cryptoadm list fips[=fips_number_list] > cryptoadm enable fips[=fips_number_list] > cryptoadm disable fips[=fips_number_list] > > The "=fips_number_list" part is optional. > The current supported FIPS number is 140, which is the default for now > also. > > Therefore, "cryptoadm enable fips" and "cryptoadm enable fips=140" > refer to the same thing.
I don't think that is desirable because the other FIPS standards that are relevant to the crypto framework aren't things we would want to enable disable based on their FIPS document number - for example they define the SHA1 algorithm but we would enable/disable that as a mechanism. Given that the admin would need to be reading the cryptoadm(1M) man page or the equivalent docs.sun.com task to find this and know about it I don't think that calling it fips-140 is a problem, I do think that having fips=140 or fips is a problem though (the former being unnecessary the later being to vague). -- Darren J Moffat
