CA/CertPolicyUpdatesDrafts: Difference between revisions

CA/CertPolicyUpdatesDrafts (view source)

Revision as of 17:40, 9 July 2012

5 bytes added , 9 July 2012

→‎Draft from March 2012 to June 2012

Kathleen Wilson

Confirmed users, Administrators

5,526

edits

@@ Line 13: / Line 13: @@
 == 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. The term "externally-operated" means that the private key of the intermediate certificate is not created and operated by the 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.
+* 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/or 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.
+** 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, [[CA:How_to_apply | Applying for root inclusion in Mozilla products,]] provides further details about how to submit a formal request.