CA/CertPolicyUpdatesDrafts

From MozillaWiki
< CA
Jump to: navigation, search

Drafts that have been Considered

This page is provided as a reference to show the different versions of text that were considered in regards to updating Mozilla's CA Certificate Policy to better handle subordinate CAs.

The new policy was drafted in http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html.

To view the changes that were made:

Draft proposed in October 2012

9. All certificates that are technically capable of issuing certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy and must either be technically constrained or be publicly disclosed and audited.

  • A certificate is deemed as technically capable of issuing certificates if it lacks a critical X.509v3 basicConstraints extension with the isCA boolean explicitly false. The term "subordinate CA" below refers to any organization or legal entity that is in possession or control of a certificate that is technically capable of issuing certificates.
  • These requirements include all cross-certified certificates which chain to a certificate that is included in Mozilla's CA Certificate Program.
  • For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. The anyExtendedKeyUsage MUST NOT appear within this extension.
    • If the certificate includes the id-kp-serverAuth extended key usage, then the certificate MUST include the Name Constraints X.509v3 extension. The Name Constraints extension MUST contain a dNSName permittedSubtrees constraint that only contains domains for which the issuing 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 there are no such dNSNames (e.g. because the certificate is for issuing IP-address-based certificates), then the certificate must contain a dNSNames constraint that prohibits all DNS names.
    • If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use.
  • All certificates that are technically capable of issuing certificates, that are not technically constrained, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program MUST be publicly disclosed by the CA that has their certificate included in Mozilla's CA Certificate Program. The CA with a certificate included in Mozilla's CA Certificate Program MUST disclose this information prior to any such subordinate CA issuing certificates. All disclosure of certificates MUST be made freely available and without additional requirements, including, but not limited to, registration,legal agreements, or restrictions on redistribution of the certificates in whole or in part. The Certificate Policy or Certification Practice Statement of the CA that has their certificate included in Mozilla's CA Certificate Program must specify where on that CA's website all such public disclosures are located. For a certificate to be considered publicly disclosed, the following information MUST be provided:
    • The full DER-encoded X.509 certificate
    • The corresponding Certificate Policy or Certification Practice Statement used by the subordinate CA
    • Annual public attestation of conformance to the stated certificate verification requirements and other operational criteria by a competent independent party or parties with access to the details of the subordinate CA's internal operations.

Changes in September 2012

  • Changed the first bullet point to indicate that the DER-encoded X.509 certificates of the non-technically-constrained sub-CAs also need to be disclosed.

Draft From June 2012 to September 2012

9. Each subordinate CA must either be publicly disclosed and audited in accordance with Mozilla's CA Certificate Policy or be technically constrained.

  • Each 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 information about publicly disclosed subordinate CAs may be found on the CA's website.
  • For a 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 include the anyExtendedKeyUsage KeyPurposeId.
    • If certificates chaining up to a technically constrained 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, and the Name Constraints must only permit 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 certificates chaining up to a technically constrained 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 X.509 rfc822Name Name Constraints, and the Name Constraints must only permit email addresses or mailboxes for which the CA has confirmed that the subordinate CA is authorized to use.
    • If certificates chaining up to a technically constrained 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.

Draft from March 2012 to May 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.

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. --

Retrieved from "https://wiki.mozilla.org/index.php?title=CA/CertPolicyUpdatesDrafts&oldid=1239755"