On Wednesday, May 9, 2018 at 11:42:56 PM UTC-4, Wayne Thayer wrote: > I think we have settled on the following resolution to this issue: > > Add the following to section 5.2 (Forbidden and Required Practices): > > CAs MUST NOT generate the key pairs for end-entity certificates that have > > an EKU extension containing the KeyPurposeIds id-kp-serverAuth or > > anyExtendedKeyUsage. > > > > 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 transferred using a > > different channel than the PKCS#12 file. > > > > Unless there is further discussion, I will include this language in the > final version of the policy. > > - Wayne
In one use case, the Subscriber can create their own password to start the enrollment process for the S/MIME certificate. The P12 is created, encrypted and sent to the Subscriber to be decrypted using the password. I think that asking the Subscriber to create a password with 112-bits entropy may create a very long password (over 20 characters). I think that this will take much longer than the life of the certificate (or its user) to crack. This password may also be recorded improperly or recorded on the same device as the key will reside. Could we consider reducing the size of the password? _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
