I hope some other CAs weigh in in this: Robin, Bruce, Jeremy, Daymion, Dean??? - We can’t permit user generated passwords (at least that is Tim's proposal, Wayne may not agree yet but he will when he reads this email) - We can’t distribute both the password and PKCS#12 over the same channel, even if it's a secure channel like HTTPS
We have 2 choices for where the password is generated: CA or User 1) If we require CAs to generate the passwords and they can’t distribute the necessary information to the end user via the portal over TLS (because of the dual channel requirement), then that is a relatively large impact on us, and probably anyone else that supports PKCS#12 file formats. If the channel is secure, do you need to use different channels? 2) Trying to compute the entropy of a user generated password is nearly impossible. According to NIST Special Publication 800-63, a good 20 character password will have just 48 bits of entropy, and characters after that only add 1 bite of entropy each. User stink at generating Entropy (right Tim?) NIST Special Publication 800-63 of June 2004 (revision 2) suggested the following scheme to roughly estimate the entropy of human-generated passwords (Subsequent updates of this publication gave up trying to compute entropy for user generated passwords, and when they talk about entropy they talk about 20 bits max): • The entropy of the first character is four bits; • The entropy of the next seven characters are two bits per character; • The ninth through the twentieth character has 1.5 bits of entropy per character; • Characters 21 and above have one bit of entropy per character. • A "bonus" of six bits is added if both upper case letters and non-alphabetic characters are used. • A "bonus" of six bits is added for passwords of length 1 through 19 characters following an extensive dictionary check to ensure the password is not contained within a large dictionary. Passwords of 20 characters or more do not receive this bonus because it is assumed they are pass-phrases consisting of multiple dictionary words. https://pages.nist.gov/800-63-3/ Some CAs are probably asking the user for a password during the request thus there is no need to distribute it later. But, if the Applicant provides the password over HTTPS and then later the CA provides the PKCS#12 via download link and they obtain it via HTTPS, is that a single channel that they were both distributed over? I still object to not being able to use HTTPS for collection and/or distribution of the Password and the PKCS#12. I also believe 112 bits of entropy is way too much for user generated password (assuming we want to continue supporting that option). Doug > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > bounces+doug.beattie=globalsign....@lists.mozilla.org] On Behalf Of Tim > Hollebeek via dev-security-policy > Sent: Monday, May 14, 2018 12:52 PM > To: Ryan Hurst <ryan.hu...@gmail.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: RE: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key > generation to policy) > > For the record, I posted someone else's strength testing algorithm, and > pointed out that it was bad 😊 I personally don't think building strength > testing > algorithms is hopeless, and I think good ones are very useful. I tend to > agree > with the current NIST recommendation, which is to primarily only consider > length, along with things like history, dictionary words, and reuse. > > But in this case, the public is at risk if the key is compromised, so I don't > trust a > password chosen by an end user, no matter what strength function it may or > may not pass. > > Some form of random password of sufficient length, with the randomness > coming from a CSPRNG, encoded into a more user friendly form, is the right > answer here. > > -Tim > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of > > bounces+Ryan > > Hurst via dev-security-policy > > Sent: Friday, May 4, 2018 5:19 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on > > CA key generation to policy) > > > > > > > True, but CAs can put technical constraints on that to limit the > > > acceptable > > passwords to a certain strength. (hopefully with a better > > strength-testing algorithm than the example Tim gave earlier) > > > > Tim is the best of us -- this is hard to do well :) > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/B4EQCI- > > > M91W3VFdrYnu8NKa6AWUA0Oca9gCvph6YNAo=?d=1AFyDzj7qs0LPt1qH7YZK > > X7VDlKTG3u4_pF-smh1LdxQUjK6Fx2ySSFy5RdxazxX- > > > o23v3NFfmxRdpLUwPqiW6yozAgZPzuSbInOcX3x3V3ANyskgECX5k4aeBDO0z1u > > RHJpH- > > Wb5WOBjb0n16kco9wf4jRlCIO7HgEH4pMHjx4H_POUivn493OPB7U9RX8BArU > > 5U87OFuHYndlG0UK-XvQOKqKu6t_3fatFfevp7IT8Jzm4Ze- > > xwk8jgsytRsxvWQ561mB9wFaxsYkiFLZMBHmsNDACgJKZxHouitR-aXhUbxF- > > > fKeFXogKbfDCYiYLqHOe5i8KyS8AzFNsUaZTDGJisXeUJbui5n9H3tF5berZe0DuntP > > V7a9yad9- > > > haeyu7NspHh92Niu71JNcWZks3gkKolxwuU9vUfZCdfiIIhMHniPOMkCkMl0ooM > > > gbRFl0gnAgmiNcKuIizRC9Z35_snt4pKSXAU12MQLeTdYFZMGmKYEDTvkB2L_So > > > 3AZHYfUXATSUeQQlo1zSRKZ5Mapw%3D%3D&u=https%3A%2F%2Flists.mozilla > > .org%2Flistinfo%2Fdev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
