2008/10/8 Robert Relyea <[EMAIL PROTECTED]>: > Kyle Hamilton wrote: >> >> On Tue, Oct 7, 2008 at 5:22 PM, Subrata Mazumdar >> <[EMAIL PROTECTED]> wrote: >> >>> >>> I guess that the problem is in documentation and the PSM GUI. The PSM >>> GUI should have clearly stated >>> the password policy requirement in the password change dialog window. >>> Also, NSS should have enforced the FIPS password policy during the FIPS >>> enablement. It should not >>> have enabled the internal token for FIPS with non-complaint password. >>> >> >> ...which means that the FIPS token code needs to be changed, which >> requires a new FIPS validation procedure. Unless it can be handled by >> a "vendor letter change"? I'm not a FIPS validation expert, but it's >> a problem with the code which is already validated (the token is >> passed the password to initialize itself). >> > > Our security policy already addresses this. If you set the password outside > of FIPS mode to a non-compliant password you are outside the security > policy, and thus not FIPS validated. > > bob
So, under the security policy (I'm not looking at the code right now, merely your expression of the security policy) I could set an initial password of 'a' to the FIPS token, and it would accept it for initialization? That seems... worse than counterintuitive, that seems to be violating the spirit of the security that FIPS is supposed to validate. Since 'initialization' must be part of the FIPS state machine, I would suggest that the CMVP as well as the testing lab failed its duty when evaluating the module. -Kyle H _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
