> I'd recommend making a requirement that it be "protected" by at least as many > bits of strength as the key it protects. Not doing so could cause compliance > issues: things like PCI [1] and the NIST [2] recommendations require this type of > protection.
You don't have compliance problems because my proposal is weaker than PCI and NIST (ANSI and ISO also have the same requirement). It focuses on RSA-2048 keys because those are what are prevalent in the industry. If your key is larger than 2048 bits, you can and should use more entropy in your password, and you have to if you need to comply with PCI/ANSI/ISO [1]. But that's ok because the requirement is >= 112, not exactly 112. > However, like Wayne said, this still leaves room for interpretation, if > mentioning bits is necessary, can we just bump it up to 256 rather than 112? 256 is overkill. People do have to type these passwords sometimes. 112 is the NIST-blessed strength of RSA-2048 [2]. That's why I think it's the right number. -Tim [1] I left out NIST because it isn't actually a standards body, it just provides guidance. [2] Yes, comparing symmetric and asymmetric strengths gets all applesy and orangey sometimes, but it's in the right ballpark, and it's a useful number since it's widely used and you can point to something to justify it.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
