On Mon, May 14, 2018 at 11:50 AM Doug Beattie via dev-security-policy < 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
