CA/CertPolicyUpdatesDrafts

This page is provided as a reference to show the different versions of text that have been considered in regards to updating Mozilla's CA Certificate Policy.

For the current proposed text, see http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

Draft from June 2011 to Feb 2012

• 9. The CA must do one of the following for each external third party that issues certificates. (Any external third party that can directly cause the issuance of a certificate must be treated as a subordinate CA, meeting one of the following two requirements.)
  • Implement technical controls to restrict the subordinate CA to only issue certificates within a specific set of domain names which the CA has confirmed that the subordinate CA has registered or has been authorized by the domain registrant to act on the registrant's behalf. Such technical controls must be documented in the CA's Certificate Policy or Certification Practice Statement, and reviewed by a competent independent party as part of the CA's annual audit. Acceptable technical controls include but are not limited to X.509 dNSName Name Constraints as specified in RFC 5280, which are marked as critical.
  • Publicly disclose the subordinate CA along with the subordinate CA's corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of the subordinate CA's conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations. The subordinate CA's verification requirements and operational criteria must satisfy the requirements of the Mozilla CA Certificate Policy. The CA's Certificate Policy or Certification Practice Statement must indicate where the list of publicly disclosed subordinate CAs may be found on the CA's website.

• 10. When an external third party verifies certificate subscriber information on behalf of the CA, the CA must perform appropriate additional due diligence, including at least domain name verification, before the CA may issue the certificate.

--

Draft from March 2012 to June 2012

• 9. Each externally-operated subordinate CA must either be audited in accordance with Mozilla's CA Certificate Policy or be technically constrained. Any external third party that can directly cause the issuance of a certificate must be treated as an externally-operated subordinate CA. All externally-operated subordinate CA certificates must include pathLenConstraint in the Basic Constraints extension, and the path length must be consistent with the contract between the CA and the subordinate CA.
  • Each externally-operated subordinate CA that is not technically constrained must be publicly disclosed, along with the subordinate CA's corresponding Certificate Policy or Certification Practice Statement and public attestation of the subordinate CA's conformance to the stated certificate verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations. The subordinate CA's certificate verification requirements and operational criteria must satisfy the requirements of Mozilla's CA Certificate Policy. The CA's Certificate Policy or Certification Practice Statement must indicate where the list of publicly disclosed subordinate CAs may be found on the CA's website.
  • For an externally-operated subordinate CA to be considered technically constrained, the subordinate CA certificate (and any intermediate certificates chaining up to that certificate) must include an Extended Key Usage (EKU) extension specifying the extended key usage(s) it is authorized to issue certificates for, and the EKU must not included the anyExtendedKeyUsage KeyPurposeId. The CA must also have additional technical and contractual restrictions in place to ensure that the subordinate CA fully complies with Mozilla's CA Certificate Policy. Such controls must be documented in the CA's Certificate Policy or Certification Practice Statement, and reviewed by a competent independent party as part of the CA's annual audit.
  • If certicates chaining up to the technically constrained externally-operated subordinate CA certificate may be used for TLS WWW server authentication, then the EKU of the subordinate CA's intermediate certificate(s) must include id-kp-serverAuth. Additionally, the subordinate CA's intermediate certificate(s) must also include X.509 dNSName Name Constraints as specified in RFC 5280, and the Name Constraints must only include domains for which the CA has confirmed that the subordinate CA has registered or has been authorized by the domain registrant to act on the registrant's behalf.
  • If certicates chaining up to the technically constrained externally-operated subordinate CA certificate may be used for email protection, then the EKU of the subordinate CA's intermediate certificate(s) must include id-kp-emailProtection. Additionally, the subordinate CA's intermediate certificate(s) must also include rfc822Name Name Constraints as specified in RFC 5280, and the Name Constraints must only include email addresses or mailboxes for which the CA has confirmed that the subordinate CA is authorized to use.
  • If certicates chaining up to the technically constrained externally-operated subordinate CA certificate may be used for signing of downloadable executable code, then the EKU of the subordinate CA's intermediate certificate(s) must include id-kp-codeSigning.
  • Alternate methods of technical controls that are intended to be used instead of Name Constraints must be publicly reviewed and approved according to Mozilla's process that begins with submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product. Mozilla's wiki page, Applying for root inclusion in Mozilla products, provides further details about how to submit a formal request.