== Example and Template ==
Here is a The template and an example of below show the information that the output produced during verification of CA must provide for a CA's root inclusion/update request, showing the information that the CA must provide.
* [https://docs.google.com/document/d/1lKSW0WqThxeIMzQwyo7-uwqF8hH3e069lHW2KE78vAM/edit?usp=sharing Template (Google Doc)]
* [https://ccadb-public.secure.force.com/mozilla/PrintViewForCase?CaseNumber=00000341 Example] -- links to view of the an Example Root Inclusion Case in CCADB
* Note that the certificate data will be extracted directly from the PEM of the certificate, so the CA should attach the PEM of the root certificate to the Bugzilla bug, or provide a link to the certificate on their website.
Mozilla's process is public-facing, so all information that will be taken under consideration during the root inclusion request must be publicly available and provided by the CA via the Bugzilla bug report.
== General information about the associated organization CA Primary Point of the CA Contact (POC) == # Name#* This is the name by which the CA is most commonly known.# URL In addition to company website # Organizational type - One or more of the following choices that most accurately represents your CA's organization: Private Corporation, Public Corporation, Government Agency, Commercial Organization, International Organization, Non-Profit Organization, Academic Institution, Consortium, NGO. #* Note that information listed in some cases the CA may be of a hybrid typetemplate and example above, e.g., a corporation established by the government. For government CAs, the type of government should be noted, e.g., national, regional/state/provincial, or municipal.)# Primary market / customer base#* Which types of customers does the CA serve? #* Are there particular vertical market segments in which it operates? #* Does 's must provide the CA focus its activities on a particular country or other geographic region?# Impact to Mozilla Users#* If your CA will only issue certificates within your organization or contact information for a small number of websites, then rather than including your root certificate in NSS, please consider having your CA hierarchy cross-signed by an [https://wiki.mozilla.org/CA/Included_CAs already-included CA]. If your CA will be issuing certificates to the public or to a large number of websites, then please respond to the following questions.#* Why does the CA need to have their root certificate directly included in Mozilla’s products, rather than being signed by another CA’s root certificate that is already included in NSS?#* Does this CA have root certificates included in any other major browsers? If yes, which? If no, why not?#* Describe the types of Mozilla users who are likely to encounter your root certificate as relying parties while web browsing (HTTPS servers doing SSL), sending/receiving email to their own MTA (SMTPS, IMAPS servers doing SSL), sending/receiving S/MIME email (S/MIME email certs), etc. #* Mozilla CA certificate policy: #** We will determine which CA certificates are included in software products distributed through mozilla.org, based on the benefits and risks of such inclusion to typical users of those products. #** We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software products === CA Primary Point of Contact (POC) ===A CA may have more than at least one person filling the role of Primary Point of Contact (POC), and may use a contractor as one of the POCs. The CA must have one or more people within the CA’s organization who jointly have authority to speak on behalf of the CA, and to direct whatever changes the review process or Mozilla’s CA Communications require. At least one of the CA’s POCs should also be in a position to make commitments for the CA and be held accountable by the CA.
The POCs will:
* [mailto:certificates@mozilla.org Inform Mozilla] when there is a change in the organization, ownership, CA policies, or in the POCs that Mozilla should be aware of, as per
** [http://ccadb.org/policy#2-contact-information Common CCADB Policy]
** [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#8-ca-operational-changes Mozilla's Root Store Policy]
* [mailto:certificates@mozilla.org Provide Mozilla] with updated contact information if a new person becomes a POC.
# Use the CA’s website to contact a person at the CA to confirm that at least one of the POCs that have been provided does indeed have the authority to perform the responsibilities listed above on behalf of the CA.
# If a contractor is also used as a POC, then contact the POC that was previously verified to confirm that the CA has indeed enlisted the help of the contractor.
== Technical information about each root certificate ==
The information listed in this section must be provided for each root CA whose certificate is to be included in Mozilla, or whose metadata is to be modified.
# Certificate Name
#* This is the "friendly name" to be used when displaying information about the root, e.g., "GeoTrust Global CA". It is typically identical to or a variant of the CN found within the Subject attribute of the root CA certificate itself.
# Certificate Issuer Field
#* The Organization Name and CN in the Issuer must have sufficient information about the CA Organization.
# Certificate Summary
#* A summary about this root certificate, it's purpose, and the types of certificates that are issued under it.
# Root Certificate URL
#* A public URL through which the CA certificate can be directly downloaded.
# SHA1 fingerprint
# Valid from (YYYY-MM-DD)
#* The date from which the root CA certificate is valid.
# Valid to (YYYY-MM-DD)
#* The date until which the root CA certificate is valid.
# Certificate Version (should be 3)
#* The X.509 certificate version
# Certificate Signature Algorithm
# Signing key parameters
#* For RSA keys, the modulus length, for example, 2048 or 4096 bits.
#* For ECC keys, the named curve, for example, NIST Curve P-256, P-384, or P-512.
# Test website URL -- if you are requesting to enable the Websites (SSL/TLS) trust bit
#* URL to a website whose SSL cert chains up to this root. Note that this can be a test site.
#* Please provide the 3 URLs to the test websites as described in Section 2.2 of the BRs: "The CA SHALL host test Web pages that allow Application Software Suppliers to test their software with Subscriber Certificates that chain up to each publicly trusted Root Certificate. At a minimum, the CA SHALL host separate Web pages using Subscriber Certificates that are (i) valid, (ii) revoked, and (iii) expired
#* Make sure you test it yourself in Firefox first, by doing the following:
#*# Create a new Firefox Profile for testing, as described in Mozilla's knowledge base articles: [http://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles Profile Manager] and [http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows Creating a new Firefox Profile].
#*# Import the root certificate as described [[PSM:Changing_Trust_Settings#Trusting_an_Additional_Root_Certificate|here]].
#*# Set OCSP hard fail as described [[CA/Required_or_Recommended_Practices#OCSP|here]].
#*# Clear browser history
#*# Browse to the test website.
#*# Open the [https://developer.mozilla.org/en-US/docs/Tools/Web_Console Web Console] to check for any warnings (e.g. SHA-1, etc.) that should be addressed.
#** Intermediate CA certificates are expected to be distributed to the certificate subjects (the holders of the private keys) together with the subjects' own certificates. Those subject parties (e.g. SSL servers) are then expected to send out the intermediate CA certificates together with their own certificates whenever they are asked to send out their certificates. That is required by SSL/TLS.
#** Certificate authorities MUST advise their subscribers that all intermediate certificates should be installed in the servers containing the dependent subscriber certificates.
# Example certificates
#* If this root does not issue certificates for SSL, then provide example certificate(s) issued within the hierarchy rooted at this root, including the full certificate chain(s).
# Certificate Revocation Lists (CRLs)
#* URL(s) at which the CRL(s) may be obtained -- for end-entity certs and for intermediate CAs.
#* The value that nextUpdate is set to in the CRLs for end-entity certificates.
#* The sections of your CP/CPS documentation that state the requirements about frequency of updating CRL.
#* Note the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV guidelines:] CRLs MUST be updated and reissued at least every seven days, and the nextUpdate field value SHALL NOT be more ten days
# OCSP (OCSP is required for the SSL trust bit to be enabled)
#* The OCSP URI that is in the AIA of your subscriber certificates.
#* The maximum time elapsing from the revocation of an end entity or CA certificate until OCSP responders are updated to reflect that revocation.
#* The sections of your CP/CPS specifying availability and update requirements for the OCSP service.
#** [https://cabforum.org/extended-validation/ CA/Browser Forum's EV Guidelines] Section 26(b): “If the CA provides revocation information via an Online Certificate Status Protocol (OCSP) service, it MUST update that service at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days.”
#* You must test that your OCSP service is compatible with the Firefox browser.
#** See: https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#OCSP
#** OCSP responders should be set up to listen on a standard port (e.g. port 80), because firewalls may block ports other than 80/443.
# Requested Trust Bits
#* State which of the two trust bits you are requesting to be enabled for this root. One or more of:
#** Websites (SSL/TLS)
#** Email (S/MIME)
#* Mozilla’s standpoint is that we should operate the root program in terms of minimizing risk. One way that we can minimize risk is by not enabling more trust bits than CAs absolutely require.
# SSL Validation Type
#* Indicate the levels of SSL validation that are used for certificates within this root's hierarchy. One or more of:
#** DV -- The ownership of the domain name is verified, but the identity/organization of the subscriber is not verified.
#** OV -- In addition to verifying the domain ownership, you also validate the organization to be listed in the O field - making sure public record and government resources can verify the address, existence, and good legal standing of the organization itself. Verifying that the whois listed address matches the verified address, and any other additional checks that a given CA lists in its CPS.
#** EV - Verification meets the requirements of the CA/Browser Forum [https://cabforum.org/extended-validation/ CA/Browser Forum's EV Guidelines]
# If EV certificates are issued within the hierarchy rooted at this root, the EV policy OID(s) associated with those EV certificates.
=== Test!!! ===
You must Test your certificates and test websites! They must be fully compliant with Mozilla's Root Store Policy and the appropriate RFC's, and CA/Browser Forum Baseline Requirements (if requesting the SSL/TLS trust bit).
* If requesting to enable the Websites (SSL/TLS) trust bit, then you must perform all of the following tests
** Revocation: Browse to https://certificate.revocationcheck.com/ and enter the Test Website URL. Make sure there are no errors listed in the output.
*** If certificate.revocationcheck.com does not know about the root cert, then use the 'Certificate Upload' tab to directly input the PEM for the certificates.
** The CA MUST check that they are not issuing certificates that violate any of the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] (BRs).
** Mozilla WILL check that the CA is not issuing certificates that violate any of the BRs by performing the following tests.
*** Browse to https://crt.sh/
*** Enter the SHA-1 or SHA-256 Fingerprint for the root certificate. Then click on the 'Search' button.
*** When the certificate information is shown, along the left column under Certificate, click on the "Run cablint" and "Run x509lint" links. Each of these will add a row to the table, showing the test results.
*** All errors must be resolved/fixed. Warnings should also be either resolved or explained.
** If you have not yet issued public certificates in your CA hierarchy, then you can test using:
*** https://crt.sh/linttbscert
**** [https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg07855.html Instructions]
** Alternatively, you may use the test code directly via Github:
*** BR Lint Test: https://github.com/awslabs/certlint
*** X.509 Lint Test: https://github.com/kroeckx/x509lint
*** All errors must be resolved/fixed. Warnings should also be either resolved or explained.
** [[CA:TestErrors|Test Errors]] - Meaning and recommended solutions to errors that CAs have run into while doing the tests listed above.
If you are requesting to enable EV treatment, then you must also perform the [[PSM:EV_Testing_Easy_Version | PSM EV Testing]]
* You must provide successful output from the [https://tls-observatory.services.mozilla.com/static/ev-checker.html EV Checking Tool].
== CA Hierarchy information for each root certificate ==
The information listed in this section must be provided for each root certificate to be included in Mozilla, or whose metadata is to be modified.
If Mozilla accepts and includes your root certificate, then we have to assume that we also accept any of your future sub-CAs and their sub-CAs. Therefore, the selection criteria for your sub-CAs and their sub-CAs will be a critical decision factor. As well as the documentation and auditing of operations requirements that you place on your sub-CAs and their sub-CAs.
# CA Hierarchy
#*A description of the PKI hierarchy rooted at or otherwise associated with this root CA certificate.
#** List and/or describe all of the subordinate CAs that are signed by this root.
#** Identify which of the subordinate CAs are internally-operated; e.g. list the subordinate CAs that operated by the CA organization associated with the root CA. For example, this might include subordinate CAs created to issue different classes or types of end entity certificates to the general public: Class 1 vs. class 2 certificates, qualified vs. non-qualified certificates, EV certificates vs. non-EV certificates, SSL certificates vs. email certificates, and so on.
#*** It might also include subordinate CAs operated for the benefit of specific third parties. In this case note that we do ''not'' require that the CA submit a complete customer list; rather we are interested in the general type and nature of the third-party arrangements.
# Sub CAs Operated by 3rd Parties
#*If this root has any subordinate CA certificates that are operated by external third parties, then provide the information listed in the [[CA/Subordinate_CA_Checklist|Subordinate CA Checklist]]
#* If the CA functions as a super CA such their CA policies and auditing don't apply to the subordinate CAs, then those CAs must apply for inclusion themselves as separate trust anchors.
# Cross-Signing
#* List all other root certificates for which this root certificate has issued cross-signing certificates.
#* List all other root certificates that have issued cross-signing certificates for this root certificate.
#* If any such cross-signing relationships exist, it is important to note whether the cross-signing CAs' certificates are already included in the Mozilla root store or not.
# Technical Constraints or Audits of Third-Party Issuers.
#* As per section 5.3 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy], provide the required data for all of your non-technically-constrained subordinate CA certificates that chain up to certificates in Mozilla's CA program. This data may be provided as follows:
#** Already-included CAs may provide this information directly in the [http://ccadb.org/cas/intermediates CCADB].
#** If you need to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificate Root Program" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Root Program)
== Verification Policies and Practices ==
We rely on publicly available documentation and audits of those documented processes to ascertain that the CA takes reasonable measures to confirm the identity and authority of the individual and/or organization of the certificate subscriber.
If the CP/CPS documents are not in English, then the CP/CPS documents that are relevant to the root inclusion request '''must be translated into English'''. For all of the items listed below, provide both a pointer to the original document (and section or page number of the relevant text) as well as the translated text.
# Documentation: CP, CPS, and Relying Party Agreements
#*The publicly accessible URLs to the document repository and the published document(s) describing how certificates are issued within the hierarchy rooted at this root, as well as other practices associated with the root CA and other CAs in the hierarchy, including in particular the Certification Practice Statement(s) (CPS) and related documents.
#*The document(s) and section number(s) where the "Commitment to Comply" with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] may be found, as per section 2.2 in BRs.
#* [[CA/Required_or_Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|CP/CPS Documents will be reviewed]], and must contain sufficient information for Mozilla and the CA Community to evaluate the CA's processes in regards to Mozilla's policies and the CA/Browser Forum's Baseline Requirements.
#** English translations must be provided for the relevant CP/CPS documents, and must match the current version of the CP/CPS documents.
# Audits
#* The publicly accessible URLs to the published document(s) relating to independent audit(s) of the root CA and any CAs within the hierarchy rooted at the root. For example, for WebTrust for CAs audits this would be the "audit report and management assertions" document available from the webtrust.org site or elsewhere.
#** As per section 3.1 of [https://www.mozilla.org/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy], we need a publishable (non-confidential) statement or letter from an auditor (who meets the requirements of the Mozilla CA Certificate Policy) that states that they have reviewed the practices as outlined in the CP/CPS for these roots and their CA hierarchies, and that the CA does indeed follow these practices and meets the requirements of one or more of:
#** WebTrust "Principles and Criteria for Certification Authorities 2.0" or later and "WebTrust Principles and Criteria for Certification Authorities – SSL Baseline with Network Security – Version 2.0" or later (as applicable to SSL certificate issuance) in WebTrust Program for Certification Authorities;
#** WebTrust "Principles and Criteria for Certification Authorities - Extended Validation SSL 1.4.5” or later in WebTrust Program for Certification Authorities;
#** "Requirements on CA practice", in ETSI TS 101 456 V1.4.3 or later version, Policy requirements for certification authorities issuing qualified certificates (only applicable to electronic signature certificate issuance; applicable to either the "QCP public" or "QCP public + SSCD" certificate policies);
#** "Requirements on CA practice", in ETSI TS 102 042 V2.3.1 or later version, Policy requirements for certification authorities issuing public key certificates (as applicable to the "EVCP" and "EVCP+" certificate policies, DVCP and OVCP certificate policies for publicly trusted certificates - baseline requirements, and any of the "NCP", "NCP+", or "LCP" certificate policies);
#** “Trust Service Providers practice” in ETSI EN 319 411-1 v1.1.1 or later version Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements, specifying a policy or policies appropriate to the trust bit(s) being applied for;
#*** For Websites trust bit (need BR compliance audit) the CA must comply to EN 319 411-1 for "TLS" on level DV or OV or IV, and for "eMail" on level "LCP or NCP".
#*** For EV treatment the CA must comply with EN 319 411-1 with the policy requirements identified for EVCP.
#** “Trust Service Providers practice” in ETSI EN 319 411-2 v2.1.1 or later version Policy and security requirements for Trust Service Providers issuing certificates; Part 2: Requirements for trust service providers issuing EU qualified certificates, specifying a policy or policies appropriate to the trust bit(s) being applied for.
#*** For QWACs the CA must comply with EN 319 411-2 with the policy requirements identified for QCP-w. Note: QCP-w defined in EN 319 411-2 builds on EVCP defined in EN 319 411-1.
#* Audits performed after January 2013 need to include verification of compliance with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forum Baseline Requirements] if SSL certificates may be issued within the CA hierarchy, and the audit statement shall indicate the results.
#** Carefully review with your auditor:
#*** https://www.mozilla.org//about/governance/policies/security-group/certs/policy/#required-audits
#*** https://www.mozilla.org//about/governance/policies/security-group/certs/policy/#public-audit-information
#* When audit statements are provided by the company requesting CA inclusion rather than having an audit report posted on the website such as cert.webtrust.org, the Mozilla process requires doing an independent verification of the authenticity of audit statements that have been provided. Provide the website and email address for the company that provided the audit statement.
#** If the information is available from the auditor's (or other third-party's) web site or from another authoritative web site (for example, [http://www.webtrust.org/ webtrust.org] for WebTrust reports), please provide the URL where the information can be found.
#** If you provide the information yourself (e.g., it is hosted on your own web site), please provide us with contact information for the auditor (or other third party).
#** Otherwise please ask the auditor (or other third party) to contact us directly and provide us the audit report(s) or other information.
#* The audit should not be more than a year old. If it is, then provide an estimate of when the updated audit report will be available. While ETSI Certificates may be valid for 3 years, it is our expectation that there is an annual renewal/review process for the ETSI Certificate to remain valid.
#* Renewed root certificates also need to be included in audits. If the root certificate was created after the most recent audit, then provide an estimate of when the new audit report (that includes the operations of the new root) will be available.
#* Government CAs
#** According to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#required-audits Mozilla's Root Store Policy], the audit must be performed according to criteria that is equivalent to one (or more) of ETSI TS 101 456, ETSI TS 102 042, ETSI EN 319 411, or WebTrust. The government’s auditing agency should provide a statement about which of these their government criteria is equivalent to.
# SSL Verification Procedures
#* If you are requesting to enable the Websites (SSL/TLS) trust bit...
#** URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the domain referenced in an SSL cert is owned/controlled by the subscriber.
#*** [[CA/Required_or_Recommended_Practices#Verifying_Domain_Name_Ownership|Recommended Practices for Verifying Domain Name Ownership]]
#** If a challenge-response mechanism via email is used to confirm the ownership/control of the domain name, then provide the list of email addresses that are used for verification.
#*** [[CA/Forbidden_or_Problematic_Practices#Non-Standard_Email_Address_Prefixes_for_Domain_Ownership_Validation | Potentially Problematic Practices in regards to Email Address Prefixes]] -- The list that the CA uses must either match or be a subset of the list in this wiki page.
#** Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks in 2011).
#*** Specify the procedure for additional verification of a certificate request that is blocked.
#** If OV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity, existence, and authority of the organization to request the certificate.
#*** There should be a description of the types of resources that are used to confirm the authenticity of the information provided by the certificate subscriber, what data is retrieved from public resources, and how that data is used for verification of the entity referenced in the certificate.
#** If EV verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that pertain to EV and describe the procedures for verifying the ownership/control of the domain name, and the verification of identity, existence, and authority of the organization to request the EV certificate.
#*** The EV verification documentation must meet the requirements of the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV Guidelines], and must also provide information specific to the CA's operations.
# Email Address Verification Procedures
#* If you are requesting to enable the Email (S/MIME) trust bit...
#** URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying that the email address to be included in the certificate is owned/controlled by the certificate subscriber.
#** [[CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control | Recommended Practices for Verifying Email Address]]
#*** Note that per the Mozilla policy this verification must be done ''in addition to'' any verification of the subscriber’s legal identity.
#** If subscriber identity verification is performed, then provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that describe the procedures for verifying the identity and authority of the certificate subscriber.
# Code Signing Subscriber Verification Procedures
#* No longer applicable: Mozilla is no longer accepting requests to enable the Code Signing trust bit, because we plan to remove the Code Signing trust bit in the next version of Mozilla's CA Certificate Policy.
# Multi-factor Authentication
#* Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance or specify the technical controls that are implemented by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.
#** For each account that can access the certificate issuance system, do you have the log-in procedure require something in addition to username/password?
#** Specify the form factor that you use. Examples of multi-factor authentication include smartcards, client certificates, one-time-passwords, and hardware tokens.
#** This must apply to all accounts that can cause the approval and/or issuance of end-entity certificates, including your RAs and sub-CAs, unless there are technical controls that are implemented and controlled by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses.
#** If technical controls are used instead of multi-factor auth for any accounts, then specify what those technical controls are.
# Network Security
#* CAs must maintain current best practices for network security, and have qualified network security audits performed on a regular basis. The [https://www.cabforum.org/ CA/Browser Forum] has published a document called [https://cabforum.org/network-security/ Network and Certificate System Security Requirements] which should be used as guidance for protecting network and supporting systems.
#* Confirm that you have done the following, and will do the following on a regular basis:
#** Maintain network security controls that at minimum meet the [https://cabforum.org/network-security/ Network and Certificate System Security Requirements.]
#** Check for mis-issuance of certificates, especially for high-profile domains.
#** Review network infrastructure, monitoring, passwords, etc. for signs of intrusion or weakness.
#** Ensure Intrusion Detection System and other monitoring software is up-to-date.
#** Confirm that you will be able to shut down certificate issuance quickly if you are alerted of intrusion.
== Baseline Requirements Self Assessement ==
If you are requesting the Websites (TLS/SSL) trust bit for your root certificate, then you must perform a [[CA/BR_Self-Assessment|BR Self Assessment]] to ensure that your CP and CPS documents and your practices comply with the [https://cabforum.org/baseline-requirements-documents/ CA/Browser Forums' Baseline Requirements] (BRs).
* [[CA/BR_Self-Assessment|BR Self Assessment]]
== Response to Mozilla's CA Required or Recommended Practices ==
Review Mozilla's [[CA/Required_or_Recommended_Practices | Required or Recommended Practices]] If your practices differ from any of these recommended practices, then describe those differences and explain how the concern(s) are addressed.
* [[CA/Required_or_Recommended_Practices | CA Recommended Practices]]
== Response to Mozilla's list of Forbidden or Problematic Practices ==
Review Mozilla's list of [[CA/Forbidden_or_Problematic_Practices | Forbidden or Problematic Practices.]] For each one, state if it is or is not applicable. For the ones that are applicable, provide URLs and section/page number information pointing directly to the sections of the CP/CPS documents that are relevant, and explain how you address the concern(s).
* [[CA/Forbidden_or_Problematic_Practices | Forbidden or Problematic Practices]]
