Wayne, This going to require 19 randomly generated Base64 characters and that does not include removing common confused characters which will drive up the length a bit more, but if this is what the Mozilla risk assessment came up with, then we’ll all have to comply. I hope there is a sufficiently long time for CAs to change their processes and APIs and to roll out updated training and documentation to their customers (for this unplanned change).
Did you consider any changes based on Jakob’s comments? If the PKCS#12 is distributed via secure channels, how strong does the password need to be? Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Monday, May 14, 2018 4:54 PM To: Doug Beattie <doug.beat...@globalsign.com>; mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy <dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>> wrote: 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 > Or the user could generate the key :-) > 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). Perhaps the following language is a workable solution to the first objection? PKCS#12 files must employ an encryption key and algorithm that is sufficiently strong to protect the key pair for its useful life based on current guidelines published by a recognized standards body. PKCS#12 files MUST be encrypted and signed; or, MUST have a password that exhibits at least 112 bits of entropy, and the password MUST be transmitted via a secure channel. I really don't seem a benefit to user generation of these passwords - either they are weak and memorable, or sufficiently complicated that there's little value in being able to choose it. Doug _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
