View source for CA/Quantifying Value

The purpose of this page is to provide guidance to first-time root store applicants about the information they may provide to help Mozilla determine if the benefit of including their root certificate is worth the risk of including it. We are guided by Principle 4 of the Mozilla Manifesto: “Individuals’ security and privacy on the internet are fundamental and must not be treated as optional,” and by our root store policy which requires that the CA operator provide services relevant to the users of our software products. In other words, we will evaluate the CA operator and its CA(s) based on the value they present for our users and the protections they will provide for user security and privacy. The value of adding a particular root CA certificate must be worthwhile enough for Mozilla’s end users before Mozilla is willing to accept the risks associated with including a new CA in Mozilla’s root store. 

It is the CA operator’s responsibility to establish the value to Mozilla’s end users of including their root certificate(s). The applicant must present an explanation of the benefits to our users so that the community can identify, measure, value, and understand the benefits of including the root certificate and determine whether it is worth the risk of including it. These applicant-provided explanations cannot just be marketing fluff or mere self-promotion. Justifications must be detailed, objective, and supported by data to establish credible facts and create legitimacy and trust.  Relevant facts show value only when they contribute towards meeting the needs of Mozilla’s users.

=== What Kinds of Benefits can a CA provide to Mozilla? ===

A benefit is a measurable contribution that supports Mozilla in working toward and reaching its goal of providing security and privacy to its users. For instance, we want CAs that will provide us with a good return on the investment of the time and resources we put into the management of the Mozilla root program. 

Supporting factors include:

* Communities served  
* Quality of services offered 
* Risk management and risk reduction 
* Lower rate of CA compliance incidents 
* Less time and effort needed for CA oversight  
* Positive effects on Mozilla’s reputation for privacy  
* Positive effects on Mozilla’s reputation for security 
* Firefox user retention 

=== What Information can a CA Provide to Plead their Case? ===

Additionally, below are some questions that new root store applicants should also answer:

==== Reasons Why Applicant is Applying for Inclusion ====

# Why does the applicant want its root CA certificate(s) to be included by default in Mozilla’s root store?

==== Whether the Applicant Commits Sufficient Resources to Compliance ====

# Who are the applicant’s beneficial owners?
# What is the applicant’s investment in CA infrastructure and personnel?
# What is the applicant’s long-term commitment to investing in CA infrastructure and personnel? 
# What system development resources have been allocated to ensure compliance, and how are they sufficient? 
# What is the CA’s compliance budget?  How is it determined? Is it constrained by rules, processes, or procedures that will hamper the allocation of sufficient resources for compliance?

==== Whether the Applicant Employs Skilled Personnel ====

# How well and closely does the CA track changes to industry requirements? How does the CA plan to stay informed and compliant with the ever-changing requirements?
# Who are applicant’s personnel who are familiar with CABF and IETF standards? How much PKI domain experience do these skilled employees have?  What is the depth of their understanding and knowledge?  (Risks arise when CAs stop investing in training or employ people who aren’t as qualified as the people who the CA presented during the inclusion process.) 
# To what extent have CA personnel reviewed the CA incidents that have been reported in Bugzilla over the past several years? How have systems been designed to avoid similar mistakes?

==== Whether the Applicant’s Operations are Designed for Continued Compliance ====

# How are the CA’s systems designed?
# How well are CA processes documented and programmatically enforced for compliance with industry requirements?
# How does the applicant reduce operational risk and maintain an error-free, compliant operation?
# What pre-issuance lint testing does the CA use? What other automation does the CA use to reduce risk?
# What mechanisms ensure that the CA system is agile to change when required for privacy, security, or compliance reasons? 
# What is the quality of execution? What measures does the CA implement to quickly address compliance incidents?

==== Whether the Applicant has a Good Compliance Management Program ==== 

# How robust is the applicant’s compliance and risk management program? 
# What evidence can the applicant provide to demonstrate that it has a good compliance program in place? How long has such program been operational? On what compliance framework is it based?
# How familiar is the applicant with the annual risk assessment required by section 5 of the Baseline Requirements? (Note that it requires 1. the identification of foreseeable internal and external threats; 2. an assessment of the likelihood and potential damage of these threats; and 3. an assessment of the sufficiency of the policies, procedures, information systems, technology, and other arrangements that the CA has in place to counter such threats.)
# How does the applicant exercise care when deciding to take on risks? What are applicant’s processes for mitigating or accepting risks?

==== Whether a Knowledgeable Third Party has Reviewed the CA Systems ==== 

# What initial assessments (e.g. a detailed controls review) have been conducted on CA systems?  What criteria were used?  Were assessments performed by a knowledgeable assessor?
# What are the auditor’s qualifications for previous and current audit statements?