CA/Quantifying Value: Difference between revisions

From MozillaWiki
< CA
Jump to navigation Jump to search
m (Protected "CA/Quantifying Value" ([Edit=Allow confirmed users only] (indefinite) [Move=Allow confirmed users only] (indefinite)))
m (Added "new")
 
(2 intermediate revisions by the same user not shown)
Line 1: Line 1:
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.
__NOTOC__
== Purpose and Principles ==


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.
The purpose of this page is to guide '''new''' Certification Authority (CA) operators in preparing a Value Statement to accompany their root store inclusion request.


=== What Kinds of Benefits can a CA provide to Mozilla? ===
Mozilla’s goal is to determine whether the benefit to Mozilla’s users of including a particular root certificate outweighs the inherent risks of trust delegation. This aligns with Principle 4 of the Mozilla Manifesto:


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.  
''“Individuals’ security and privacy on the internet are fundamental and must not be treated as optional.”''


Supporting factors include:
Mozilla’s Root Store Policy requires that CAs included by default in Mozilla products provide services relevant to and beneficial for Mozilla users. Therefore, your Value Statement must explain, with objective and verifiable evidence, how your CA enhances user security, privacy, and trust.


* Communities served 
Submissions that rely on unverifiable marketing claims such as “millions of users” or “trusted nationwide” will not be accepted. Assertions must be supported by data, audit evidence, and credible facts that demonstrate value and legitimacy.
* 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? ===
Mozilla evaluates Value Statements according to three main themes:


Additionally, below are some questions that new root store applicants should also answer:
* '''User Value and Impact''' – measurable benefits to Mozilla’s users.
* '''Compliance Maturity and Risk Management''' – the CA’s demonstrated ability to operate responsibly and minimize incidents.
* '''Transparency and Public Accountability''' – openness in operations, incident handling, and participation in Mozilla’s public compliance ecosystem.


==== Reasons Why Applicant is Applying for Inclusion ====
Opaque or government-operated CAs that cannot demonstrate measurable user benefit and transparency will not meet Mozilla’s inclusion expectations.


# Why does the applicant want its root CA certificate(s) to be included by default in Mozilla’s root store?
== 1. User Value and Impact ==


==== Whether the Applicant Commits Sufficient Resources to Compliance ====
=== Policy Rationale ===
Mozilla prioritizes inclusion of CAs that provide direct and measurable benefits to users of Mozilla products such as Firefox and Thunderbird. The goal is not market share, but tangible improvements in user security, privacy, accessibility, and trust.


# Who are the applicant’s beneficial owners?
=== Guidance ===
# What is the applicant’s investment in CA infrastructure and personnel?
Provide quantitative data—such as the number of active certificates, user communities served, and measurable improvements in security or privacy outcomes. Describe how your CA’s inclusion benefits Mozilla users specifically, not just governments, enterprises, or the general PKI ecosystem.
# 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 ====
=== Questions to Address ===


# 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?
* What specific communities or regions does your CA serve? (e.g., under-represented languages, educational or nonprofit sectors, local businesses)
# 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.)  
* How many certificates currently in use serve Mozilla users directly (e.g., TLS certificates for Firefox users, S/MIME certificates for Thunderbird users)?
# 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?
* How does your CA’s presence improve user security or privacy (e.g., faster revocation handling, DNSSEC adoption, improved domain validation)?
* How does your CA align with Mozilla’s mission to make the internet open, accessible, and secure for everyone?
* What measurable outcomes demonstrate your CA’s impact (e.g., incident-free issuance rate, percentage of automated issuance, reduction in mis-issuance events)?
* How does your CA’s inclusion provide a return on Mozilla’s investment in oversight (e.g., reduced need for manual review, consistent audit quality)?


==== Whether the Applicant’s Operations are Designed for Continued Compliance ====
== 2. Compliance Maturity and Risk Management ==


# How are the CA’s systems designed?
=== Policy Rationale ===
# How well are CA processes documented and programmatically enforced for compliance with industry requirements?
Mozilla’s trust decisions depend on each CA’s proven ability to maintain secure, reliable, and compliant operations. Demonstrating compliance maturity shows that your CA can be trusted to minimize risk and respond effectively to incidents.
# 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 ====  
=== Guidance ===
Explain the design, governance, and continuous improvement of your compliance program. Include evidence such as incident rates, automation levels, staff qualifications, and independent audits. Vague assurances of compliance are insufficient—your answers should demonstrate operational depth and accountability.


# How robust is the applicant’s compliance and risk management program?
=== Questions to Address ===
# 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 ====  
==== Commitment and Resourcing ====


# 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?
* Who are the applicant’s beneficial owners, and what is their long-term commitment to operating a compliant CA?
# What are the auditor’s qualifications for previous and current audit statements?
* What investments have been made in CA infrastructure, staffing, and compliance functions?
* What portion of your organization’s resources are allocated to compliance and risk management?
* How is your compliance budget determined, and how do you ensure it remains adequate as operations evolve?
 
==== Personnel and Expertise ====
 
* Who within your organization tracks updates to CA/Browser Forum, IETF, or audit-related standards?
* How are personnel trained and kept current on changing industry requirements?
* What relevant experience and technical qualifications do key compliance and PKI staff possess?
* How has your CA reviewed and learned from past incidents reported in Bugzilla or other forums, and how were lessons integrated into operations?
 
==== Operational Design for Compliance ====
 
* How are systems architected to ensure compliance with the Baseline Requirements and Mozilla Root Store Policy?
* What automated mechanisms (e.g., pre-issuance linting, CAA checking, multi-perspective domain validation) reduce operational risk?
* How are processes documented and enforced programmatically?
* How is agility maintained so that systems can be updated quickly when security or compliance requirements change?
* What performance metrics or KPIs do you use to monitor compliance effectiveness?
 
==== Compliance Program and Third-Party Oversight ====
 
* What formal compliance or risk management framework does your organization follow (e.g., ISO 27001, NIST 800-53, WebTrust/ETSI criteria)?
* How long has the program been operational, and how is it reviewed or improved over time?
* What independent assessments or audits have been conducted? Who performed them, and what are the auditor’s qualifications?
* How are identified deficiencies documented, tracked, and remediated?
* How does management ensure “tone at the top” for compliance culture and accountability?
 
== 3. Transparency and Public Accountability ==
 
=== Policy Rationale ===
Trust in the web PKI ecosystem depends on transparency. Mozilla expects CAs to operate openly—sharing information about compliance, participating in public review processes, and responding constructively to feedback.
 
=== Guidance ===
Provide examples of your CA’s public engagement, such as participation in Bugzilla incident threads, CCADB updates, or industry working groups. Describe your processes for disclosure, communication, and corrective action. Applicants that maintain open, timely communication demonstrate greater reliability.
 
=== Questions to Address ===
 
* How has your CA participated in Mozilla’s public compliance ecosystem (e.g., Bugzilla discussions, incident reporting, or CCADB submissions)?
* What internal procedures ensure timely public disclosure of incidents and follow-up actions?
* How does your organization communicate and cooperate with Mozilla or other root programs during incident handling?
* What public resources (e.g., repository, transparency reports, mailing list participation) reflect your CA’s accountability?
* What steps have you taken to promote openness, standardization, or community improvements in PKI operations?
 
== 4. Summary and Expectations ==
 
A strong Value Statement should:
 
* Demonstrate direct benefit to Mozilla users through quantitative and verifiable evidence.
* Establish compliance maturity by describing structured, well-resourced, and independently reviewed practices.
* Show transparency and accountability through public engagement, open incident reporting, and continuous improvement.
 
Submissions that are purely promotional or that lack measurable, user-focused evidence will be downgraded.
Mozilla values trustworthiness, openness, and clear benefit to users above all other factors.
 
== 5. Examples of Strong vs. Weak Responses ==
 
The following examples illustrate how CAs can strengthen their Value Statements.
Responses should focus on measurable data, Mozilla-user relevance, and demonstrable transparency, rather than general marketing claims or compliance slogans.
 
=== User Value and Impact ===
'''Strong:''' “Issued approximately 220,000 TLS certificates currently observed in use by Firefox users in South America and sub-Saharan Africa. We provide OCSP and CRL endpoints with 99.98% uptime and maintain full IPv6 and DNSSEC support to enhance end-user reliability.”
'''Weak:'''  “We are trusted by millions of users across the country and are compliant with eIDAS and ISO standards.”
 
=== Compliance Maturity and Risk Management ===
'''Strong:'''  “Our automated pre-issuance linting prevents 99.7% of potential misissuance events. We have maintained an incident rate of less than 0.3% since 2022 and conduct quarterly internal control reviews aligned with WebTrust and ETSI criteria.”
'''Weak:'''  “We follow all CAB Forum and WebTrust requirements and maintain full compliance at all times.”
 
=== Personnel and Expertise ===
'''Strong:'''  “Our compliance team of six staff includes two former WebTrust auditors and a CAB Forum working group participant. All staff complete annual PKI and information security training. Lessons learned from Bugzilla incidents are reviewed quarterly to inform process updates.”
'''Weak:'''  “Our team is highly skilled and continuously monitors compliance developments.”
 
=== Transparency and Public Accountability ===
'''Strong:'''  “We have reported and discussed three compliance incidents in Bugzilla since 2023, provided public updates within 24 hours of discovery, and published post-incident reviews on our transparency page.”
'''Weak:'''  “We disclose incidents to auditors and regulators as required and keep Mozilla informed as needed.”
 
=== Mozilla-User Alignment ===
'''Strong:'''  “Our inclusion supports Firefox users in regions where no other publicly trusted CA provides local-language validation and low-cost S/MIME services. This directly enhances accessibility and privacy for small organizations and NGOs using Mozilla products.”
'''Weak:'''  “Our services are essential to national e-government programs and are trusted by enterprises and citizens alike.”
 
 
''The section above is intended as illustrative guidance only. It does not prescribe specific thresholds or metrics but highlights the qualities of complete, verifiable, and user-focused Value Statements.''

Latest revision as of 20:31, 23 November 2025

Purpose and Principles

The purpose of this page is to guide new Certification Authority (CA) operators in preparing a Value Statement to accompany their root store inclusion request.

Mozilla’s goal is to determine whether the benefit to Mozilla’s users of including a particular root certificate outweighs the inherent risks of trust delegation. This aligns with Principle 4 of the Mozilla Manifesto:

“Individuals’ security and privacy on the internet are fundamental and must not be treated as optional.”

Mozilla’s Root Store Policy requires that CAs included by default in Mozilla products provide services relevant to and beneficial for Mozilla users. Therefore, your Value Statement must explain, with objective and verifiable evidence, how your CA enhances user security, privacy, and trust.

Submissions that rely on unverifiable marketing claims such as “millions of users” or “trusted nationwide” will not be accepted. Assertions must be supported by data, audit evidence, and credible facts that demonstrate value and legitimacy.

Mozilla evaluates Value Statements according to three main themes:

  • User Value and Impact – measurable benefits to Mozilla’s users.
  • Compliance Maturity and Risk Management – the CA’s demonstrated ability to operate responsibly and minimize incidents.
  • Transparency and Public Accountability – openness in operations, incident handling, and participation in Mozilla’s public compliance ecosystem.

Opaque or government-operated CAs that cannot demonstrate measurable user benefit and transparency will not meet Mozilla’s inclusion expectations.

1. User Value and Impact

Policy Rationale

Mozilla prioritizes inclusion of CAs that provide direct and measurable benefits to users of Mozilla products such as Firefox and Thunderbird. The goal is not market share, but tangible improvements in user security, privacy, accessibility, and trust.

Guidance

Provide quantitative data—such as the number of active certificates, user communities served, and measurable improvements in security or privacy outcomes. Describe how your CA’s inclusion benefits Mozilla users specifically, not just governments, enterprises, or the general PKI ecosystem.

Questions to Address

  • What specific communities or regions does your CA serve? (e.g., under-represented languages, educational or nonprofit sectors, local businesses)
  • How many certificates currently in use serve Mozilla users directly (e.g., TLS certificates for Firefox users, S/MIME certificates for Thunderbird users)?
  • How does your CA’s presence improve user security or privacy (e.g., faster revocation handling, DNSSEC adoption, improved domain validation)?
  • How does your CA align with Mozilla’s mission to make the internet open, accessible, and secure for everyone?
  • What measurable outcomes demonstrate your CA’s impact (e.g., incident-free issuance rate, percentage of automated issuance, reduction in mis-issuance events)?
  • How does your CA’s inclusion provide a return on Mozilla’s investment in oversight (e.g., reduced need for manual review, consistent audit quality)?

2. Compliance Maturity and Risk Management

Policy Rationale

Mozilla’s trust decisions depend on each CA’s proven ability to maintain secure, reliable, and compliant operations. Demonstrating compliance maturity shows that your CA can be trusted to minimize risk and respond effectively to incidents.

Guidance

Explain the design, governance, and continuous improvement of your compliance program. Include evidence such as incident rates, automation levels, staff qualifications, and independent audits. Vague assurances of compliance are insufficient—your answers should demonstrate operational depth and accountability.

Questions to Address

Commitment and Resourcing

  • Who are the applicant’s beneficial owners, and what is their long-term commitment to operating a compliant CA?
  • What investments have been made in CA infrastructure, staffing, and compliance functions?
  • What portion of your organization’s resources are allocated to compliance and risk management?
  • How is your compliance budget determined, and how do you ensure it remains adequate as operations evolve?

Personnel and Expertise

  • Who within your organization tracks updates to CA/Browser Forum, IETF, or audit-related standards?
  • How are personnel trained and kept current on changing industry requirements?
  • What relevant experience and technical qualifications do key compliance and PKI staff possess?
  • How has your CA reviewed and learned from past incidents reported in Bugzilla or other forums, and how were lessons integrated into operations?

Operational Design for Compliance

  • How are systems architected to ensure compliance with the Baseline Requirements and Mozilla Root Store Policy?
  • What automated mechanisms (e.g., pre-issuance linting, CAA checking, multi-perspective domain validation) reduce operational risk?
  • How are processes documented and enforced programmatically?
  • How is agility maintained so that systems can be updated quickly when security or compliance requirements change?
  • What performance metrics or KPIs do you use to monitor compliance effectiveness?

Compliance Program and Third-Party Oversight

  • What formal compliance or risk management framework does your organization follow (e.g., ISO 27001, NIST 800-53, WebTrust/ETSI criteria)?
  • How long has the program been operational, and how is it reviewed or improved over time?
  • What independent assessments or audits have been conducted? Who performed them, and what are the auditor’s qualifications?
  • How are identified deficiencies documented, tracked, and remediated?
  • How does management ensure “tone at the top” for compliance culture and accountability?

3. Transparency and Public Accountability

Policy Rationale

Trust in the web PKI ecosystem depends on transparency. Mozilla expects CAs to operate openly—sharing information about compliance, participating in public review processes, and responding constructively to feedback.

Guidance

Provide examples of your CA’s public engagement, such as participation in Bugzilla incident threads, CCADB updates, or industry working groups. Describe your processes for disclosure, communication, and corrective action. Applicants that maintain open, timely communication demonstrate greater reliability.

Questions to Address

  • How has your CA participated in Mozilla’s public compliance ecosystem (e.g., Bugzilla discussions, incident reporting, or CCADB submissions)?
  • What internal procedures ensure timely public disclosure of incidents and follow-up actions?
  • How does your organization communicate and cooperate with Mozilla or other root programs during incident handling?
  • What public resources (e.g., repository, transparency reports, mailing list participation) reflect your CA’s accountability?
  • What steps have you taken to promote openness, standardization, or community improvements in PKI operations?

4. Summary and Expectations

A strong Value Statement should:

  • Demonstrate direct benefit to Mozilla users through quantitative and verifiable evidence.
  • Establish compliance maturity by describing structured, well-resourced, and independently reviewed practices.
  • Show transparency and accountability through public engagement, open incident reporting, and continuous improvement.

Submissions that are purely promotional or that lack measurable, user-focused evidence will be downgraded. Mozilla values trustworthiness, openness, and clear benefit to users above all other factors.

5. Examples of Strong vs. Weak Responses

The following examples illustrate how CAs can strengthen their Value Statements. Responses should focus on measurable data, Mozilla-user relevance, and demonstrable transparency, rather than general marketing claims or compliance slogans.

User Value and Impact

Strong: “Issued approximately 220,000 TLS certificates currently observed in use by Firefox users in South America and sub-Saharan Africa. We provide OCSP and CRL endpoints with 99.98% uptime and maintain full IPv6 and DNSSEC support to enhance end-user reliability.” Weak: “We are trusted by millions of users across the country and are compliant with eIDAS and ISO standards.”

Compliance Maturity and Risk Management

Strong: “Our automated pre-issuance linting prevents 99.7% of potential misissuance events. We have maintained an incident rate of less than 0.3% since 2022 and conduct quarterly internal control reviews aligned with WebTrust and ETSI criteria.” Weak: “We follow all CAB Forum and WebTrust requirements and maintain full compliance at all times.”

Personnel and Expertise

Strong: “Our compliance team of six staff includes two former WebTrust auditors and a CAB Forum working group participant. All staff complete annual PKI and information security training. Lessons learned from Bugzilla incidents are reviewed quarterly to inform process updates.” Weak: “Our team is highly skilled and continuously monitors compliance developments.”

Transparency and Public Accountability

Strong: “We have reported and discussed three compliance incidents in Bugzilla since 2023, provided public updates within 24 hours of discovery, and published post-incident reviews on our transparency page.” Weak: “We disclose incidents to auditors and regulators as required and keep Mozilla informed as needed.”

Mozilla-User Alignment

Strong: “Our inclusion supports Firefox users in regions where no other publicly trusted CA provides local-language validation and low-cost S/MIME services. This directly enhances accessibility and privacy for small organizations and NGOs using Mozilla products.” Weak: “Our services are essential to national e-government programs and are trusted by enterprises and citizens alike.”


The section above is intended as illustrative guidance only. It does not prescribe specific thresholds or metrics but highlights the qualities of complete, verifiable, and user-focused Value Statements.

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