Mozilla CA Certificate FAQ

As noted in the policy, our decision will be based on the benefits and risks of such inclusion to typical users. We will judge such benefits and risks according to the following criteria, among others:

the end user functions made possible by the CA, and the benefits of such functions to typical users;
the manner in which the CA operates to support such functions, and whether or not the CA operates in a manner likely to cause undue risk or technical problems for typical users;
the size of the CA's customer base and target market (i.e., the number of entities to which the CA has issued certificates or is likely to issue certificates);
the number of users that communicate with or otherwise interact with the CA's customers (for example, a given CA might issue relatively few certificates, but those certificates might be issued to particular web sites used by a large number of users); and
whether the CA serves a particular market of interest to all or part of our user base (for example, a given CA might serve a country or geographic region within which we wish to promote localized product versions).

For more information please see the answers to the questions below.

No. The Mozilla Foundation will not charge fees to or accept other considerations from CAs.

We can't anticipate all the reasons why we might discontinue including a CA certificate. We're simply putting CAs and others on notice that we might do so in the future if we ever felt such an action were necessary and appropriate.

That being said, there are at least two reasons why we might choose to drop a CA's certificate from the included default set (or, alternatively, reset the CA's certificate's trust bits so as to not allow automatic validation of certificates issued by the CA):

the risk/benefit tradeoff for including the CA's certificate becomes significantly less favorable (for example, if the CA fails to maintain good security practices in issuing certificates and other aspects of its operation); or
including the CA's certificate results in a significant support burden for Mozilla developers (for example, if the CA issues certificates that do not conform to the formats expected by the products' code).

We've included in the policy several examples of particular practices that might cause us to consider removing a CA's certificate(s) from the default set (or to not accept the CA into the default set in the first place). However note that this list is not exhaustive.

We mean that the certificates issued by the CA should be used (or usable) in some context relevant to typical users, i.e., individual users, not necessarily security-knowledgeable, who use Firefox, Thunderbird, and related products for personal tasks such as online shopping and banking, using other access-controlled web sites and services, submitting personal information to companies and government agencies, exchanging personal email with others, downloading and installing new software on their personal systems, and comparable activities.

In particular, the CA may do one or more of the following:

issue certificates directly to typical users, e.g., for use in signing and encrypting email;
issue certificates to operators of web sites used (or likely to be used) by typical users; or
issue certificates to developers of Firefox or Thunderbird extensions or related software likely to be downloaded, installed, and executed by typical users.

In general, no. If a CA is used only to issue certificates for use within a given organization (a "private" or "internal" CA) then we would not see any real benefit to typical users to including a CA certificate for that CA in the default set. A similar objection applies to CAs that are not purely internal but are still operated primarily in support of a particular organization's private business objectives (for example, a CA that issues certificates to that organization's suppliers and customers to facilitate selling to or buying from the organization in question).

Perhaps. We'll make our decision based on the potential benefit to typical users, and this in turn will depend on the type of consortium it is and how "public" the consortium is (e.g., to what extent organizations and individuals in general may join the consortium). For example, if your consortium conducts scientific research, creates industry standards, or otherwise provides services that are of some public benefit then we would consider including your CA certificate in the default set, particularly if consortium membership were open to the general public (organizations and/or individuals) on reasonable terms.

Yes in both cases. The Mozilla Foundation will not discriminate between CAs based on their location, and in particular will not discriminate between U.S.-based CAs and CAs based outside the U.S. (The only possible exception to this would be in cases where the Mozilla Foundation as a U.S.-based entity might be restricted in some way by U.S. laws. For example, it's not clear whether U.S. export control regulations would restrict the Mozilla Foundation from distributing CA certificates for CAs located in countries such as Cuba, North Korea, etc.)

We will also consider including CA certificates for CAs that offer services only in particular countries or other geographic regions (for example, a CA based in Japan that offers web server certificates only to Japanese companies). Even though such a CA's customers may be located only in a certain region, those customers (certificate holders) may communicate with others around the world. (For example, a web server with a certificate from a Japan-only CA may still receive connections from Firefox users located outside Japan.)

Yes, if the CA meets the requirements outlined in the policy, some of which have been designed to handle exactly this case.

In particular, we will accept the results of CA evaluations done by any competent independent party with the necessary access to information about the CA's internal operations; we do not require that the evaluator be an accounting professional (e.g., as in WebTrust audits) or have other formal qualifications or authorizations.

For example, a nonprofit group not able to afford a WebTrust audit could seek a volunteer who would be willing to perform a CA evaluation on a pro bono basis. If the volunteer evaluator is competent and independent (as defined in the policy) then we would accept the results of such an evaluation as valid.

We consider verification measures to be reasonable if they appear to accomplish the stated purpose and are consistent with common industry practice. For example, one common industry practice is to verify the subscriber's control of a domain by sending an email message to an authorized person for that domain, as determined by WHOIS data, and looking for an affirmative response to that message. We consider this to be a "reasonable measure" in the sense we mean.

We simply mean that we might change the policy in the future to add, modify, or delete requirements for subscriber verification, based on evolving industry practices regarding verification and our own assessment of those practices.

First, we might change the policy in the future to add, modify, or delete particular sets of formal criteria, as new criteria are published or we have time to evaluate existing published criteria other than those currently mentioned in the policy. Second, we might choose to accept a different set of criteria for a given CA, provided that the CA can show a clear mapping between those criteria and one or more of the sets of criteria we mention in the polcy.

We'll look at the evaluator's formal qualifications, their resume, their publicly-available writings and work products, and other peoples' opinions of them.

First, note that this issue doesn't arise in the case where an evaluator is specifically authorized to perform particular types of CA evaluations. If an accounting firm has been authorized to perform WebTrust CA audits (i.e., through the formal AICPA/CICA program) or a test lab has been authorized to perform ETSI TS 101 456 audits (e.g., by a government agency implementing a national digital signature law) then we'll take that as prima facie evidence that the firm or test lab in question is competent to perform a CA evaluation.

On the other hand, if the evaluator has no such formal authorization then we'll need to assess competence in other ways; such ways might include:

looking at the evaluator's published resume or other public documents to see the extent of their experience relating to security evaluations, security risk analyses, and other types of information system audits and evaluations;
reviewing the publicly-available writings of the evaluator, potentially including the results of previous audits or evaluations they've done, in order to determine their level of knowledge regarding CAs and CA-related questions; and
asking other people to provide public statements regarding the evaluator's experience, knowledge, honesty and objectivity.

In general we are looking for information that describes what your CA does and how it operates, in order that we may assess what benefits and risks are associated with including your CA certificate and whether you have met the requirements outlined in the policy.

The requested information falls into the following general classes (note that if you are submitting requests for multiple certificates to be included, please provide information for all CAs associated with such certificates):

general information about your CA(s), such as you might provide on a public web site; for example, this might include
- a description of your organization
- certificate-related services that you provide
- target markets (e.g., industry sectors, customer groups, geographic regions, etc.)
- contact information
information as to how you have met the policy's requirements regarding subscriber verification;
information as to how you have met the policy's requirements regarding third-party evaluation of your CA's operations according to an acceptable set of criteria;
any other information you wish the Mozilla Foundation to take into account when evaluating your request

Wherever possible please provide publicly-accessible URLs pointing to documents in cross-platform formats such as HTML or PDF. If your documents are not available in English translation then please provide summary information in English sufficient to answer the questions above.

Note that we may elect to publish any or all submitted information for use by users and others; please do not submit any information that you consider to be proprietary or otherwise not suitable for public release. (As an exception to this, note that we will not publish private contact information, e.g., phone numbers and/or email addresses of individual CA employees; we suggest you provide such information to us in order that we may communicate directly with you in the future if needed.)

Submitted requests will be handled as follows:

Requests sent to certificates@mozilla.org will be forwarded to a person designated by mozilla.org staff to handle such requests. To use Mozilla project jargon, this person is the "module owner" for CA certificate issues. Requests submitted directly through the Mozilla project's Bugzilla bug tracking system for the "mozilla.org" product and "CA certificates" component will be automatically assigned to the module owner.
If a bug report has not already been entered for the request, the module owner will open up a new bug report corresponding to the request in Bugzilla.
The module owner will acknowledge the request by sending an email to the contact address given in the request, including the Bugzilla bug number and associated URL. ()
The module owner will publish information about the request to the netscape.public.mozilla.crypto newsgroup and associated mozilla-crypto mailing list, and will invite public comment on whether the request should be granted or denied.
The module owner and other interested parties will discuss the request in Bugzilla (not in the newsgroup and mailing list). You should follow the bug report discussion to track the progress of the request, and should provide any additional information as required, in the form of comments or attachments to the bug report.
Based on the results of the public discussion the module owner will decide whether to grant or deny your request. If the request is granted, the module owner will arrange with the appropriate developer(s) for your CA certificate to be added to the default set in a future version of Mozilla. If your request is denied then the module owner will provide you with the reason(s) for the denial.
If we require additional information from you, and you do not provide the information within 30 days of its being requested, then the module owner will deny your request (resolving the Bugzilla bug report as "WONTFIX") and ask that you not resubmit it until you can provide the necessary information.
If you believe that your request has been wrongly denied, or if the module owner is unresponsive or otherwise does not handle your request in a timely manner, then you may appeal to mozilla.org staff by sending an email to staff@mozilla.org and asking them to intervene.

Mozilla CA Certificate FAQ (Proposed)

Details of the Mozilla CA Certificate Policy