Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
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
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
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
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Doug, On Thu, May 10, 2018 at 10:57 AM Doug Beattie <doug.beat...@globalsign.com> wrote: > Hi Wayne, > > > > I’m OK with this as long as this permits the password (fully or partially > generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS > (a single channel). > > > This language is not intended to permit both the password and PKCS#12 file to be transmitted over HTTPS. In an earlier message I said that I'd like to hear from other CAs who feel that this exception is necessary, but none have commented. Given the difficultly in carving out an exception limited to the scenario you described and the [perhaps marginal] increase in security that this requirement provides even in your scenario, I'm not inclined to try to accommodate it. If the proposed language is not clear in stating that the password and PKCS#12 file cannot both be transmitted over HTTPS, please let me know. Doug > > > > > > *From:* Wayne Thayer [mailto:wtha...@mozilla.com] > *Sent:* Wednesday, May 9, 2018 11:43 PM > *To:* Doug Beattie <doug.beat...@globalsign.com> > *Cc:* mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org> > *Subject:* Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition > on CA key generation to policy) > > > > > > 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 > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
Hi Wayne, I’m OK with this as long as this permits the password (fully or partially generated by the CA) and PKCS#12 file to be picked up by a user over HTTPS (a single channel). Doug From: Wayne Thayer [mailto:wtha...@mozilla.com] Sent: Wednesday, May 9, 2018 11:43 PM To: Doug Beattie <doug.beat...@globalsign.com> Cc: mozilla-dev-security-policy <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy) 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: FW: Bit encoding (AW: Policy 2.6 Proposal: Add prohibition on CA key generation to policy)
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
