Confirmed users, Administrators
5,526
edits
CA/CertificatePolicyV2.1: Difference between revisions
m
Kathleen Wilson moved page CA:CertificatePolicyV2.1 to CA/CertificatePolicyV2.1 without leaving a redirect: Moved from CA: to CA/
m (Kathleen Wilson moved page CA:CertificatePolicyV2.1 to CA/CertificatePolicyV2.1 without leaving a redirect: Moved from CA: to CA/) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 32: | Line 32: | ||
In item #6 of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] a requirement was added for CAs to enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. This requirement was [[CA:Communications#September_8.2C_2011 | previously communicated,]] so all CAs are expected to already be in compliance with this requirement. | In item #6 of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] a requirement was added for CAs to enforce multi-factor authentication for all accounts capable of directly causing certificate issuance. This requirement was [[CA:Communications#September_8.2C_2011 | previously communicated,]] so all CAs are expected to already be in compliance with this requirement. | ||
In item #6 of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] a requirement was added for CAs to 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 (BR) #12. | In item #6 of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] a requirement was added for CAs to 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 (BR) #12. (Note: in version 1.3 and later of the BRs, this is in section 6.1.7) | ||
* This requirement and the exceptions listed in | * This requirement and the exceptions listed in BRs about root CA private keys being used to sign certificates apply to SSL/TLS, S/MIME, and Code Signing certificates. | ||
* Root certificates and trust anchors that are already included in NSS will be granted the time necessary to transition their existing customers to a new hierarchy. If needed, the CA shall create a new root certificate within the next year (before February 2014) and actively work to include the new root certificate in Mozilla's program and transition their customers to the new hierarchy. | * Root certificates and trust anchors that are already included in NSS will be granted the time necessary to transition their existing customers to a new hierarchy. If needed, the CA shall create a new root certificate within the next year (before February 2014) and actively work to include the new root certificate in Mozilla's program and transition their customers to the new hierarchy. | ||
* Mozilla grants an exception to the trust anchors in Mozilla's program that are signed by national policy root certificates whose corresponding national policy does not allow the subordinate CA to issue other subordinate CA certificates. | * Mozilla grants an exception to the trust anchors in Mozilla's program that are signed by national policy root certificates whose corresponding national policy does not allow the subordinate CA to issue other subordinate CA certificates. | ||
* Mozilla grants an exception to the trust anchors that are signed by a national CA who is working towards inclusion of the national root certificate, but Mozilla has requested that each subordinate CA be evaluated separately first. | * Mozilla grants an exception to the trust anchors that are signed by a national CA who is working towards inclusion of the national root certificate, but Mozilla has requested that each subordinate CA be evaluated separately first. | ||
=== Baseline Requirements === | |||
Item #12 of the [[CA:CertInclusionPolicyV2.1 | Inclusion Policy]] adds the requirement for CA operations and issuance of certificates to be used for SSL-enabled servers to also conform to version 1.1 of the [http://www.cabforum.org/documents.html CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.] | |||
* As of February 2013, SSL certificate issuance must also be audited according to the Baseline Requirements (BRs), [[CA:CertificatePolicyV2.1#Audit_Criteria | as described above.]] The first BR audit for each CA and subCA may include a reasonable list of BRs that the CA (or subCA) is not yet in compliance with. The second BR audit (the following year) is expected to confirm that the issues that were listed in the previous BR audit have been resolved. | |||
* All other dates are as specified by the CA/Browser Forum. | |||
=== Technical Constraints or Auditing/Disclosure of Intermediate Certificates === | === Technical Constraints or Auditing/Disclosure of Intermediate Certificates === | ||
| Line 46: | Line 53: | ||
** A pre-existing externally-operated subordinate CA certificate that expires before May 15, 2014 may be re-issued in order to extend the validity period of the currently-valid intermediate CA certificate until May 15, 2014. That is, the replacement certificate's notAfter date would be May 15, 2014 or earlier. | ** A pre-existing externally-operated subordinate CA certificate that expires before May 15, 2014 may be re-issued in order to extend the validity period of the currently-valid intermediate CA certificate until May 15, 2014. That is, the replacement certificate's notAfter date would be May 15, 2014 or earlier. | ||
* All certificates that are capable of being used to issue new certificates must comply with [[CA:CertInclusionPolicyV2.1 | version 2.1]] or later of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] for new certificate issuance by May 15, 2014. | * All certificates that are capable of being used to issue new certificates must comply with [[CA:CertInclusionPolicyV2.1 | version 2.1]] or later of [http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy] for new certificate issuance by May 15, 2014. | ||
== Frequently Asked Questions == | == Frequently Asked Questions == | ||
| Line 73: | Line 73: | ||
#* For each subordinate CA certificate that is being phased out and is in 'CRL/OCSP only' mode, please provide the following information: Name of SubCA (optional), SubCA Cert Hash (SHA1 or SHA256), SubCA Cert Subject Key Identifier, SubCA Cert Serial Number, Date of Last Cert Issuance, Date of Last Cert Expiration. | #* For each subordinate CA certificate that is being phased out and is in 'CRL/OCSP only' mode, please provide the following information: Name of SubCA (optional), SubCA Cert Hash (SHA1 or SHA256), SubCA Cert Subject Key Identifier, SubCA Cert Serial Number, Date of Last Cert Issuance, Date of Last Cert Expiration. | ||
# What about [https://tools.ietf.org/html/rfc6962 Certificate Transparency] Precertificate Signing Certificates? | # What about [https://tools.ietf.org/html/rfc6962 Certificate Transparency] Precertificate Signing Certificates? | ||
#* A Precertificate Signing Certificate with an EKU extension with '''only''' the Certificate Transparency OID 1.3.6.1.4.1.11129.2.4.4 is considered technically constrained according to section 9 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Policy]. The certificate's EKU extension must '''not''' include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning. | #* A Precertificate Signing Certificate with an Extended Key Usage (EKU) extension with '''only''' the Certificate Transparency OID 1.3.6.1.4.1.11129.2.4.4 is considered technically constrained according to section 9 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Policy]. The certificate's EKU extension must '''not''' include any of these KeyPurposeIds: anyExtendedKeyUsage, id-kp-serverAuth, id-kp-emailProtection, id-kp-codeSigning. | ||