On Mon, May 14, 2018 at 11:29 AM Bruce via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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?
>
> Remember that this only applies when the CA generates the key pair. If the
CA must for some reason do that, then it's reasonable to expect the CA to
secure it with a strong password.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to