Forbidden Practices: Subscriber key generation

Hi Gerv and Kathleen,

We're working on the Mozilla CA self-assessment checklist and referenced re=
quirements you have placed on CAs.  On your page of Forbidden or Problemati=
c Practices [1], you state that CAs must not generate private keys for sign=
er certificates.
CAs must never generate the key pairs for signer or SSL certificates. CAs m=
ay only generate the key pairs for SMIME encryption certificates.

The Code signing standard [2], section 10.2.4 permits CAs to generate priva=
te keys for code signing certificates.  Specifically:
If the CA or any Delegated Third Party is generating the Private Key on beh=
alf of the Subscriber where the Private Keys will be transported to the Sub=
scriber outside of the Signing Service's secure infrastructure, then the en=
tity generating the Private Key MUST either transport the Private Key in ha=
rdware with an activation method that is equivalent to 128 bits of encrypti=
on or encrypt the Private Key with at least 128 bits of encryption strength=
.. Allowed methods include using a 128-bit AES key to wrap the private key o=
r storing the key in a PKCS 12 file encrypted with a randomly generated pas=
sword of more than 16 characters containing uppercase letters, lowercase le=
tters, numbers, and symbols for transport.


The question is, if we issue Code Signing certificates via P12 files in com=
pliance with the Code Signing standard, are we out of compliance with the M=
ozilla policy?  How do you recommend we respond to this checklist question?

And the same for S/MIME and SSL certificates.  If CAs generate and then sec=
urely distribute the keys to the subscribers using similar methods, is that=
 permitted provided we implement similar security, or does that practice ne=
ed to immediately stop?  Your guidance in this area would be appreciated.

Side question: Is there a deadline when you expect to receive self-assessme=
nts from all CAs?  We've found that complying with the checklist means a ma=
jor update to our CPS (among other things...), and I suspect most other CAs=
 will also need a major update.

Doug

[1] https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices
[2] https://casecurity.org/wp-content/uploads/2016/09/Minimum-requirements-=
for-the-Issuance-and-Management-of-code-signing.pdf


Doug Beattie
Product Mangement
GMO GlobalSign, Inc.
Portsmouth, NH USA

0
Doug
11/14/2017 9:53:50 PM
mozilla.dev.security.policy 1337 articles. 2 followers. Post Follow

2 Replies
59 Views

Similar Articles

[PageSpeed] 38

On 14/11/17 21:53, Doug Beattie wrote
> The question is, if we issue Code Signing certificates via P12 files
> in compliance with the Code Signing standard, are we out of
> compliance with the Mozilla policy?  How do you recommend we respond
> to this checklist question?

Mozilla does not have policies relating to code signing. We would
therefore expect CAs to arrange things such that their code signing
activities fall outside the scope of the Mozilla policy. The scope
statement in the policy section 1.1, and it seems to me that the easiest
technical way to achieve this is to do code signing activities under an
intermediate which is technically constrained so it cannot issue email
or server certs.

> And the same for S/MIME and SSL certificates.  If CAs generate and
> then securely distribute the keys to the subscribers using similar
> methods, is that permitted provided we implement similar security, or
> does that practice need to immediately stop?  Your guidance in this
> area would be appreciated.

For SSL, I would say it needs to immediately stop. Although see:
https://github.com/mozilla/pkipolicy/issues/107

For S/MIME, as you can see, the Problematic Practices page permits it.

> Side question: Is there a deadline when you expect to receive
> self-assessments from all CAs?  We've found that complying with the
> checklist means a major update to our CPS (among other things...),
> and I suspect most other CAs will also need a major update.

I believe Kathleen did put a date in the CA Communication. If you need
more time, contact certificates@mozilla dot org with your good reasons :-)

Gerv
0
Gervase
11/22/2017 3:56:53 PM
Thanks Gerv.

Code signing certificates don't contain EKU of id-kp-serverAuth, id-kp-emai=
lProtection so it's out of scope for the policy.  I didn't take the stateme=
nt "key pairs for signer" and narrow that down to "S/MIME signing", now I g=
et it.

For S/MIME you said the Problematic Practices page permits CAs to generate =
keys, but to be clear, it's only permitted for the Encryption certificates,=
 and not for S/MIME signature certificates.  If you have one S/MIME cert fo=
r both signing and encryption then CAs must not generate the keys pairs.  I=
s that right?

> -----Original Message-----
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=3Dglobalsign.com@lists.mozilla.org] On Behalf Of Ger=
vase
> Markham via dev-security-policy
> Sent: Wednesday, November 22, 2017 10:57 AM
> To: mozilla-dev-security-policy@lists.mozilla.org
> Subject: Re: Forbidden Practices: Subscriber key generation
>=20
> On 14/11/17 21:53, Doug Beattie wrote
> > The question is, if we issue Code Signing certificates via P12 files
> > in compliance with the Code Signing standard, are we out of compliance
> > with the Mozilla policy?  How do you recommend we respond to this
> > checklist question?
>=20
> Mozilla does not have policies relating to code signing. We would therefo=
re
> expect CAs to arrange things such that their code signing activities fall=
 outside
> the scope of the Mozilla policy. The scope statement in the policy sectio=
n 1.1,
> and it seems to me that the easiest technical way to achieve this is to d=
o code
> signing activities under an intermediate which is technically constrained=
 so it
> cannot issue email or server certs.
>=20
> > And the same for S/MIME and SSL certificates.  If CAs generate and
> > then securely distribute the keys to the subscribers using similar
> > methods, is that permitted provided we implement similar security, or
> > does that practice need to immediately stop?  Your guidance in this
> > area would be appreciated.
>=20
> For SSL, I would say it needs to immediately stop. Although see:
> https://github.com/mozilla/pkipolicy/issues/107
>=20
> For S/MIME, as you can see, the Problematic Practices page permits it.
>
> > Side question: Is there a deadline when you expect to receive
> > self-assessments from all CAs?  We've found that complying with the
> > checklist means a major update to our CPS (among other things...), and
> > I suspect most other CAs will also need a major update.
>=20
> I believe Kathleen did put a date in the CA Communication. If you need mo=
re
> time, contact certificates@mozilla dot org with your good reasons :-)
>=20
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
0
Doug
11/22/2017 6:28:53 PM
Reply: