Closed Bug 763758 Opened 7 years ago Closed 7 years ago

Updating Mozilla's CA Certificate Policy - Version 2.1

Categories

(NSS :: CA Certificate Root Program, task)

task
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: kwilson, Assigned: kwilson)

References

Details

(Whiteboard: Published)

Attachments

(1 file, 3 obsolete files)

The proposed draft of version 2.1 of Mozilla’s CA Certificate Policy is here:

http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/

The red text indicates the proposed new text. 
The bold text indicates the sections that are to be deleted.

The proposed changes are as follows.

~~~ Inclusion Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

* Proposed removing “DSA certificates with 2048-bit primes” from the fourth bullet of item #4 because is it incorrect to say that these are invalid (bug #724038).

* Added Third bullet to item #6 in accordance with previous CA Communications that stated that RA functions need to be protected by multi-factor authentication.

* Added fourth bullet to item #6 to require that intermediate certificates be used to sign end-entity certs; e.g. the trust anchor that is included in NSS should not directly sign end-entity certs.

* Proposed removing the current item #8, because it is redundant with the CAB Forum’s Baseline Requirement #11.1.

* Added #9 to address the concerns that some subordinate CAs are neither audited nor technically constrained, and some RAs act as CAs but are not audited or technically constrained. These concerns are listed here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs

* Added #11 to require issuance of SSL certs to conform to the CAB Forum’s Baseline Requirements. 

* Fixed the “module owner” links in item #18.


~~~ Maintenance Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html

* As per bug #669474, changed the first sentence of item #5 from
“We require that all CAs whose certificates are distributed with our software products notify us when its policies and business practices change in regards to verification procedures for issuing certificates, or when the ownership control of the CA changes.”
To
“We require that all CAs whose certificates are distributed with our software products notify us when its policies and business practices change in regards to verification procedures for issuing certificates, when the ownership control of the CA's certificate(s) changes, or when ownership control of the CA's operations changes.”


~~~ Enforcement Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html

To address the concerns listed here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#Fixes_to_Version_2.0
two changes were made…

* In item #2 added “(partially or fully).

* In item #3 proposed changing
“To initiate the disablement or removal of a certificate, a representative of Mozilla will submit a bug report to”
to
“Disablement or removal of a certificate may be initiated by submitting a bug report to”

~~

These proposed changes are the culmination of over a year of discussions in the mozilla.dev.security.policy forum.
Depends on: 764013
I have created bug #764013 for legal review of the proposed changes.
Hi Kathleen,

This requirement does not comply with the Baseline Requirements section 12 which deals with "Certificate Issuance by a Root CA":
* Added fourth bullet to item #6 to require that intermediate certificates be used to sign end-entity certs; e.g. the trust anchor that is included in NSS should not directly sign end-entity certs.

Can the Baseline Requirements be used to address this issue?

Thanks, Bruce.
(In reply to Bruce Morton from comment #3)
> Hi Kathleen,
> 
> This requirement does not comply with the Baseline Requirements section 12
> which deals with "Certificate Issuance by a Root CA":
> * Added fourth bullet to item #6 to require that intermediate certificates
> be used to sign end-entity certs; e.g. the trust anchor that is included in
> NSS should not directly sign end-entity certs.
> 
> Can the Baseline Requirements be used to address this issue?
> 
> Thanks, Bruce.



I agree that BR #12 handles this much better. However, it doesn't handle all the cases that we need to consider, such as:

1) The BRs are only for SSL certs, and Mozilla's CA Cert Policy also applies to email and code signing certs. I just looked through the list of BuiltIn certs and their trust bits, and most CAs in Mozilla's program issue SSL certs, so is it safe to assume that they would apply the same hierarchy requirements to all their certs? 

It looks like there is one CA who does not issue SSL certs AND has their root sign end-entity certs directly (https://bugzilla.mozilla.org/show_bug.cgi?id=370627#c76), but I suppose it might not make sense to add policy for this one case.

2) There may be trust anchors included in NSS which are actually intermediate certs. Should those trust anchors be allowed to issue customer end-entity certs directly after the trust anchor is included in NSS?
https://bugzilla.mozilla.org/show_bug.cgi?id=557167#c16
https://bugzilla.mozilla.org/show_bug.cgi?id=489240#c28


> This requirement does not comply with the Baseline Requirements section 12
> which deals with "Certificate Issuance by a Root CA":

I would like to have the requirement work with BR12, but also apply to email and code signing certs. On the other hand, I don't want to add all the verbiage that was needed for BR12. Is there a way to do this with one sentence?
I made the following changes to
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

#9: Changed
“X.509 dNSName Name Constraints as specified in RFC 5280,"
to
“X.509 dNSName Name Constraints,"

#9: Changed
“rfc822Name Name Constraints as specified in RFC 5280,"
to
"X.509 rfc822Name Name Constraints,"

#11: Removed second bullet because it is no longer needed. The BRs are being amended to allow for non-critical name constraints until there is support in more of the major browsers.
Text Removed: “Name Constraints do not need to be marked as critical at this time.”
In reply to comment #4, perhaps we could use a notwithstanding clause. Your statement could be amended as follows:

* maintain a certificate hierarchy such that the included certificate does not directly issue end-entity certificates to customers (e.g., the included certificate signs intermediate issuing certificates); notwithstanding, the requirements of BR12 shall apply to SSL certificate issuance.
After further thought, I would like it to read more along the lines of BR #12 applies to all (not just SSL).

I changed the text to the following, and will post to mozilla.dev.security.policy for feedback. 

- maintain a certificate hierarchy such that the included certificate does not directly issue end-entity certificates to customers (e.g., the included certificate signs intermediate issuing certificates), as described in CA/Browser Forum Baseline Requirement #12;
I changed item #9 in WorkInProgress/InclusionPolicy.html to make the requirement apply to all subCAs, not just externally-operated ones. 

This is still open for discussion.
In item #9 in WorkInProgress/InclusionPolicy.html I changed two occurrences of the word "include" to "permit", as follows.

changed
"and the Name Constraints must only include domains for which the CA has"
to
"and the Name Constraints must only permit domains for which the CA has"

and

changed
"and the Name Constraints must only include email addresses or mailboxes for"
to
"and the Name Constraints must only permit email addresses or mailboxes for"

From Rob Stradling: I think "include" is a loophole: it could be interpreted as "a GeneralSubtree mentioning at least one validated domain must be included in either permittedSubtrees or excludedSubtrees".In contrast, I think "permit" clearly indicates that the dNSName Name Constraint must appear in permittedSubtrees.
The proposed version 2.1 of Mozilla's CA Certificate Policy has been updated as follows. 

~~~ Inclusion Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html (Deletions are indicated in bold text. Additions are indicated in red text.)

* Proposed removing “DSA certificates with 2048-bit primes” from the fourth bullet of item #4 because is it incorrect to say that these are invalid (bug #724038).

* Added Third bullet to item #6 in accordance with previous CA Communications that stated that RA functions need to be protected by multi-factor authentication.

* Added fourth bullet to item #6 to require that intermediate certificates be used to sign end-entity certs; e.g. the trust anchor that is included in NSS should not directly sign end-entity certs.

* Proposed removing the current item #8, because it is redundant with the CAB Forum’s Baseline Requirement #11.1.

* Added #9, #10, and #11 to address the concerns that some subordinate CAs are neither audited nor technically constrained, and some RAs act as CAs but are not audited or technically constrained. These concerns are listed here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs

* In #12 regarding acceptable audit criteria, proposed deleted ANSI X9.79-1:2001, and updated version numbers for the other listed criteria.

* Added #13 to require issuance of SSL certs to conform to the CAB Forum’s Baseline Requirements. 

* Fixed the “module owner” links in item #20.


~~~ Maintenance Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/MaintenancePolicy.html

* As per bug #669474, changed the first sentence of item #5 from
“We require that all CAs whose certificates are distributed with our software products notify us when its policies and business practices change in regards to verification procedures for issuing certificates, or when the ownership control of the CA changes.”
To
“We require that all CAs whose certificates are distributed with our software products notify us when its policies and business practices change in regards to verification procedures for issuing certificates, when the ownership control of the CA's certificate(s) changes, or when ownership control of the CA's operations changes.”


~~~ Enforcement Policy ~~~
http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/EnforcementPolicy.html

To address the concerns listed here:
https://wiki.mozilla.org/CA:CertPolicyUpdates#Fixes_to_Version_2.0
two changes were made…

* In item #2 added “(partially or fully).

* In item #3 proposed changing
“To initiate the disablement or removal of a certificate, a representative of Mozilla will submit a bug report to”
to
“Disablement or removal of a certificate may be initiated by submitting a bug report to”

~~

These proposed changes are the culmination of over a year of discussions in the mozilla.dev.security.policy forum.
Attachment #632338 - Attachment is obsolete: true
Attachment #690965 - Attachment is obsolete: true
Attachment #713212 - Attachment is obsolete: true
Gerv and Sid, as peers of the Mozilla CA Certificate Policy module, would you please do a final review of the changes to version 2.1 of Mozilla's CA Certificate Policy? Then, if you approve of the changes, please state so in this bug.

Thanks,
Kathleen
Status: NEW → ASSIGNED
I approve :-). 

Only two comments:

1) The URLs for the two modules can have intra-page anchors, i.e.:
https://wiki.mozilla.org/Modules/Activities#Mozilla_CA_Certificate_Policy
https://wiki.mozilla.org/Modules/Activities#Governance

2) "Mozilla's CA Certificate Policy defining a competent and independent auditor takes precedence over Baseline Requirement #17.6, Auditor Qualifications."

This might be less concerning to people if instead we write the more expressive:

"Mozilla's CA Certificate Policy defining a competent and independent auditor is a superset of Baseline Requirement #17.6, Auditor Qualifications, and takes precedence over it."

However, if you feel that this change would require another round of review, then we can stick with the existing text.

Gerv
(In reply to Gervase Markham [:gerv] from comment #15)
> I approve :-). 
> 
> Only two comments:

I have made both changes. 

Thanks!
Kathleen
Comment on attachment 713218 [details]
Diffs of the proposed version 2.1 to version 2.0

I approve too.  I'll even go so far as to r+ it.  :)
Attachment #713218 - Flags: review+
Announcement:
https://blog.mozilla.org/security/2013/02/15/announcing-version-2-1-of-mozilla-ca-certificate-policy/

Mozilla CA Certificate Policy Version 2.1:
http://www.mozilla.org/projects/security/certs/policy/

About the new version:
https://wiki.mozilla.org/CA:CertificatePolicyV2.1

Thanks!
Kathleen
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: Published
Product: mozilla.org → NSS
You need to log in before you can comment on or make changes to this bug.