Ryan - thanks for raising these issues again. I still have concerns about getting this specific in the policy, but since we're now headed down that road...
On Tue, May 1, 2018 at 7:13 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A few problems I see with the proposed text: > > - What is sufficient? I would go with a definition tied to the effective > strength of the keys it protects; in other words, you should protect a > 2048bit RSA key with something that offers similar properties or that > 2048bit key does not live up to its 2048 bit properties. This is basically > the same CSPRNG conversation but it's worth looking at > https://www.keylength.com/ The latest proposal replaces "sufficient" with "at least 64 bits of output from a CSPRNG". We could go back to "sufficient strength for the keys it protects", but that also leaves quite a bit of room for misinterpretation. Are there objections to "at least 112 bits of output from a CSPRNG" as Tim proposed? > > - The language should recommend that the "password" be a value that is a > mix of a user-supplied value and the CSPRNG output and that the CA can not > store the user-supplied value for longer than necessary to create the > PKCS#12. > I'm with Tim on this - it's added complexity for no real added security. - The strength of the password is discussed but PKCS#12 supports a bunch of > weak cipher suites and it is common to find them in use in PKCS#12s. The > minimum should be specified to be what Microsoft supports which is > pbeWithSHAAnd3-KeyTripleDES-CBC for “privacy” of keys and for the privacy > of certificates it uses pbeWithSHAAnd40BitRC2-CBC. > After reading your (Ryan's) blog, I was left with the impression that Windows only supports the weakest algorithms, so adding this requirement doesn't mean anything. If that's not correct, can you suggest some language? - The language requires the use of a password when using PKCS#12s but > PKCS#12 supports both symmetric and asymmetric key based protection also. > While these are not broadly supported the text should not prohibit the use > of stronger mechanisms than 3DES and a password. > > Does the following language work? If not, could you suggest something better? PKCS#12 files SHALL be encrypted and signed; or, SHALL have a password containing at least 64 bits of output from a CSPRNG, and the password SHALL be transferred using a different channel than the PKCS#12 file. > Ryan > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
