CA/Communications

From MozillaWiki
< CA
Jump to: navigation, search

The following are communications that have been sent to Certification Authorities participating in Mozilla's root program. If you have questions regarding these communications, please first review related discussions in the Mozilla dev-security-policy forum. If your questions cannot be answered in that forum, then please send email to certificates@mozilla.org.

August 2023 CA Communication and Survey

Communication and Survey: https://docs.google.com/document/d/1ieXSt3rJyOSopJnDp4wFGSugpk6pt5pJFJ55rkpb6Ks/edit?usp=sharing

The purpose of this communication and survey is to ensure that CA operators are aware of and prepared to comply with changes to the Mozilla Root Store Policy (MRSP), which we plan to publish soon as version 2.9 with an effective date of September 1, 2023.

The most significant changes to v2.9 of MRSP are:

  1. Retirement of Older Root CA Certificates
  2. Compliance with the CABF’s S/MIME BRs
  3. Security Vulnerability Reporting
  4. Removed duplication with CCADB Policy regarding Audit Requirements
  5. Annual Submission of CCADB Compliance Self-Assessment
  6. Elimination of SHA-1

Survey Responses: https://docs.google.com/spreadsheets/d/1xJ6VRs2R0tw3-QHoIRzIIO8MWWoqNs576KOxPKYsp3w/edit?usp=sharing

February 2023 CA Communication

Dear Certification Authority,

Mozilla’s Root Store Policy (MRSP) was recently updated to version 2.8.1 with an effective date of February 15, 2023, https://github.com/mozilla/pkipolicy/pull/265/files. Version 2.8.1 contains several clarifications and minor changes that may affect your organization. You need to be aware of these clarifications and changes to ensure your continued compliance with the MRSP. The following are summaries only of the actual language in the MRSP, and in the event of any conflicting interpretation, the MRSP takes precedence over these summaries:

  • You are required to follow and be aware of discussions in both the Mozilla dev-security-policy forum, https://groups.google.com/a/mozilla.org/g/dev-security-policy, and the CCADB Public List, https://groups.google.com/a/ccadb.org/g/public;
  • Your CP, CPS, or combined CP/CPS MUST clearly explain your CA’s domain validation procedures and indicate which subsection of section 3.2.2.4 of the CA/Browser Forum’s Baseline Requirements you are complying with;
  • Your CP, CPS, or combined CP/CPS MUST be updated at least every 365 days (more often is expected), and it must be reported in the CCADB in a “timely manner”, and failure to do either of these things will require that you file an incident report in Bugzilla;
  • You MUST maintain links to all historic versions of each CP, CPS, or combined CP/CPS from the creation of included CA certificates until such certificate hierarchies are no longer trusted by the Mozilla root store, and if your CA certificate was included by Mozilla before December 31, 2022, then you still must maintain links for “reasonably available historic versions” of your CPs, CPSes, or combined CP/CPSes; and
  • In the CCADB, if you elect to publish a JSON array of partial CRLs (rather than the full CRL), then the JSON Array of Partitioned CRLs must contain a critical Issuing Distribution Point extension, which shall include a URI whose value is derived from either the URI as encoded in the distributionPoint field of an issued certificate's CRL Distribution Points extension (see RFC 5280 section 5.2.5) or the URL included in the "JSON Array of Partitioned CRLs" field in the CCADB entry corresponding to the certificate for the issuing CA.

Finally, participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard user security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you very much for your continued cooperation in this pursuit.

Regards, Ben Wilson Mozilla CA Program Manager


May 2022 CA Communication and Survey

  • Read-only copy of May 2022 CA Communication and Survey
    • This link is Read Only. To submit your responses, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2022 CA Communication and Survey' survey.
    • Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a 'survey submitted' response -- there are required fields.

May 2022 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

February 2022 CA Communication

Dear Certification Authority,

Mozilla is engaged in policy review discussions to sunset the use of SHA1 for signing by CAs of CRLs, OCSP responses, and SMIME certificates. See https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/CnVjV-bFcyI/m/TFuWOy2BAwAJ

(Server certificate signing is governed by the Baseline Requirements, and effective June 1, 2022, OCSP responses related to server certificates cannot be signed with SHA1.)

One proposal is to remove SHA1 from the list of allowed signing algorithms altogether, but before we do this, I would like your proposed sunset dates for the different types of SHA1 signing you might currently perform--SMIME certificates, ARLs/CRLs, and OCSP responses for SMIME certificates.

Please participate in this important topic, which is already underway on the Mozilla dev-security-policy list. Let us know about your specific concerns and hurdles that would need to be overcome. (Some CAs have expressed willingness to quickly convert over to SHA256, while others have expressed that it is not a simple task and will require additional development work.)

Thanks, Ben Wilson (bwilson@mozilla.com) Mozilla Root Store Program

April 2021 CA Communication

  • Read-only copy of April 2021 CA Communication
    • This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey.
    • Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a 'survey submitted' response -- there are required fields.

Dear Certification Authority,

Mozilla’s Root Store Policy was recently updated to version 2.7.1 with an effective date of 1 May 2021. This version contains several changes that may affect your organization and the auditors who evaluate your PKI. These changes require you to take action to ensure your continued compliance.

Please review version 2.7.1 of Mozilla’s Root Store Policy internally, and with your auditors as well. After you and your auditors have reviewed these new requirements, complete the April 2021 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your practices. Read all survey questions first before beginning to respond.

To respond to this survey, log in to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2021 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 30-April-2021.

A compiled list of CA responses to the survey will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Ben Wilson
Mozilla CA Program Manager

April 2021 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

May 2020 CA Communication

  • Read-only copy of May 2020 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.


Dear Certification Authority,

This survey requests your input on current policy and upcoming policy changes that affect you as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'May 2020 CA Communication' survey. All CAs with root certificates included in Mozilla’s root store must submit their responses by 31-May 2020.

A compiled list of CA responses to the survey will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Kathleen Wilson
Mozilla CA Program Manager

May 2020 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

January 2020 CA Communication

  • Read-only copy of January 2020 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2020 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.


Dear Certification Authority,

Mozilla’s Root Store Policy was recently updated. The 2.7 version went into effect on 1-January 2020. This version contains a number of changes that may affect your organization and will require you to take action to comply. Please review Mozilla’s updated Root Store Policy and complete the January 2020 survey via the Common CA Database (CCADB). This survey also contains information regarding other recent and upcoming changes that may affect your Certificate Authority (CA).

As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.

To respond to this survey, log in to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘January 2020 CA Communication' survey. Please enter your response by 31 January 2020.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Wayne Thayer
Mozilla CA Program Manager

January 2020 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

November 2018 CA Communication (Underscores in dNSNames)

On November 12, 2018, the following message was sent to all CAs in the Mozilla program, alerting them to CA/Browser Forum SC12 that established a brief sunset period for the use of underscore characters in dNSNames in publicly-trusted TLS certificates.

Dear Certification Authority,

The CA/Browser Forum recently approved [1] a clarification to the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (BRs) that may affect you. Domain names containing underscore (“_”) characters are not permitted to be encoded as dNSName types in the subjectAlternativeName (SAN) field of BR-compliant certificates. This requirement derives from section 4.2.1.6 of RFC 5280 that the BRs require CAs to comply with by reference.

Section 7.1.4.2.1 of the BRs will add the following language that clarifies the existing requirement and adds a short time in which CAs must discontinue the use of underscore characters in dNSNames:

Prior to April 1, 2019, certificates containing underscore characters (“_”) in domain labels in dNSName entries MAY be issued as follows:

  • dNSName entries MAY include underscore characters such that replacing all underscore characters with hyphen characters (“-“) would result in a valid domain label, and;
  • Underscore characters MUST NOT be placed in the left most domain label, and;
  • Such certificates MUST NOT be valid for longer than 30 days.

All certificates containing an underscore character in any dNSName entry and having a validity period of more than 30 days MUST be revoked prior to January 15, 2019.

After April 30, 2019, underscore characters (“_”) MUST NOT be present in dNSName entries.

This new language will go into effect on December 10, 2018 when the IPR review period for ballot SC12 [1] is completed. At that time, CAs must be prepared to stop issuing publicly-trusted TLS certificates containing the underscore character in any dNSName with validity periods of more than 30 days.

As a participant in Mozilla's CA Certificate Program, we want you to be aware of this important change, and ask that you take any necessary steps to comply. No further action related to this change is requested at this time.

Regards,

Wayne Thayer Mozilla CA Program Manager

[1] https://cabforum.org/2018/11/12/ballot-sc-12-sunset-of-underscores-in-dnsnames/

November 2018 Responses

  • No survey was included in this CA Communication

September 2018 CA Communication

  • Read-only copy of September 2018 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'September 2018 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.


Dear Certification Authority,

Mozilla’s Root Store Policy was recently updated. The 2.6.1 version went into effect on 1-July, 2018. This version contains a number of changes that may affect your organization and will require you to take action to comply. This survey also contains information regarding other recent and upcoming changes that may affect your Certification Authority (CA).

As a participant in Mozilla's CA Certificate Program, this survey requires that you answer a set of questions.

To respond to this survey, log in to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the ‘September 2018 CA Communication' survey. Please enter your response by 30-September 2018.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Wayne Thayer
Mozilla CA Program Manager

September 2018 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

January 2018 CA Communication

  • Read-only copy of January 2018 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.


Dear Certification Authority,

2018 has already generated some important news for Certification Authorities, and as a result we are sending this message to ensure that every CA in the Mozilla program is aware of current events and impending deadlines.

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'January 2018 CA Communication' survey. Please enter your response by 9-February 2018.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Wayne Thayer
Mozilla CA Program Manager

January 2018 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

November 2017 CA Communication

  • Read-only copy of November 2017 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.

Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'November 2017 CA Communication' survey. Please enter your response by December 15, 2017.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Kathleen Wilson
Mozilla CA Program Manager

November 2017 Responses

The reports in the following links are automatically generated from data in the Common CA Database (CCADB).

May 2017 - Announcing CCADB Changes


Subject: Common CA Database (CCADB) changes May 19-21, 2017

Message:

Dear Certification Authority,

The Common CA Database (CCADB) will undergo the following changes this weekend, May 19 to May 21. During this time, the old URLs listed below will stop working, and there will be some time when the CCADB is in read-only mode.

On May 19 the following three breaking changes are planned, meaning that the old URLs will no longer work. Any links or bookmarks to these URLs will need to be updated. After these changes are made, I will also update Mozilla's wiki pages to point to the new URLs.

1) The CA login page and the domain CAs see when they are logged into the CCADB will change.
https://mozillacacommunity.force.com/
will be changed to
https://ccadb.force.com/

2) The links to reports that are published directly from the CCADB will change.
https://mozillacaprogram.secure.force.com/CA/
will be changed to
https://ccadb-public.secure.force.com/mozilla/

3) The links to CA communication responses that are published directly from the CCADB will change.
https://mozillacaprogram.secure.force.com/Communications
will be changed to
https://ccadb-public.secure.force.com/Surveys

Then on May 21 between 12am and 4am PDT, the CCADB will be in read-only mode while Salesforce performs an instance refresh to upgrade the infrastructure supporting the CCADB instance in their data centers.

Regards,
Kathleen

April 2017

Note: The deadline to reply to this survey has been extended by one week, to May 5, 2017.

  • Read-only copy of April 2017 CA Communication
    • CAs: This link is Read Only. To submit your response, you must login to the CCADB, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Make sure you click on the 'Submit' button at the bottom of the survey, and make sure you get a good 'survey submitted' response -- there are required fields.

Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program.

To respond to this survey, login to the Common CA Database (CCADB), then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'April 2017 CA Communication' survey. Please enter your response by April 28, 2017.

A compiled list of CA responses to the survey action items will be automatically and immediately published by the CCADB system.

In addition to responding to the action items in this survey, we are instituting a program requirement that you follow discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements or other program requirements. You are not required to contribute to those discussions, only to be aware of them. However, we hope you will participate and help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,
Kathleen Wilson
Mozilla CA Program Manager

April 2017 Responses

The reports in the following links are automatically generated from data in the Common CA Database.

March 2016

Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.

To respond to this survey, please login to the CA Community in Salesforce, then click on the 'COMMUNICATIONS' tab in the 'My CA' page, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016.

A compiled list of CA responses to the survey action items will be automatically and immediately published by Salesforce.

In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson, Mozilla CA Program Manager

March 2016 Responses

The following links are automatically generated from data in the CA Community in Salesforce.

May 2015

Dear Certification Authority,

This email requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by June 5, 2015, with your response to the action items by clicking on the survey link below. A compiled list of CA responses to these action items will be published.

Certification Authority: <CA Account Name>

Your Survey Link:

  • Survey Link -- IMPORTANT: CA's do NOT use the link in this wiki page! This link will NOT record your response. Please use the link that was emailed to you.

Please use the above link to read and respond to the action items. Note that you may access the above link multiple times to update your responses.

Additionally, we plan to update Mozilla's CA Certificate Policy soon, and will be discussing proposed policy updates in the mozilla.dev.security.policy forum, https://www.mozilla.org/en-US/about/forums/#dev-security-policy. We encourage you to monitor the discussions to see how the updates will impact you, and your participation in the discussions will help shape the policy updates.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson, Mozilla CA Program Manager

May 2015 Responses

May 2014

Subject: Mozilla Communication: Action requested by May 30, 2014

Dear Certification Authority,

This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by May 30, 2014, with your response to these action items. A compiled list of CA responses to the following action items will be published.

CA Certificate Inclusion Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/

CA Certificate Maintenance Policy: http://www.mozilla.org/about/governance/policies/security-group/certs/policy/maintenance/

Spreadsheet of included root certificates: http://www.mozilla.org/about/governance/policies/security-group/certs/included/

1) Ensure that Mozilla’s spreadsheet of included root certificates has the correct link to your most recent audit statement, and that the date of the audit statement is correct. As per Mozilla's CA Certificate Maintenance Policy, we require that all CAs whose certificates are distributed with our software products provide us an updated statement annually of attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties. To notify us of an updated statement of attestation, send email to certificates@mozilla.org or submit a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "mozilla.org" product. If you are not proactively sending Mozilla your updated audit statements, please create a process to do so.

Please respond with one of the following:

  • A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct.
  • B) Here is the most recent audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>
  • C) We plan to send Mozilla our current audit statement by <insert date here>.
  • D) We do not have a current audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.

2) Send Mozilla the link to your most recent Baseline Requirements audit statement. Details about Mozilla's audit requirements are listed in section 11 of Mozilla's CA Certificate Inclusion Policy. The Baseline Requirements audit statement should also be proactively sent to Mozilla each year, along with the other audit statements as described in action #1.

Please respond with one of the following:

  • A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent Baseline Requirements audit statement.
  • B) Here is the most recent Baseline Requirements audit statement for our certificates that are included in Mozilla’s CA program: <insert link here>.
  • C) We plan to send Mozilla our current Baseline Requirements audit statement by <insert date here and explain reason for delay>.
  • D) The websites (SSL/TLS) trust bit is not enabled for our certificates that are included in Mozilla's CA program.
  • E) We do not have a current Baseline Requirements audit statement for this root certificate, because <explain reason -- If phasing out use of the root then indicate date when the certs expire or when the root may be removed>.

3) Test Mozilla's new Certificate Verification library with your CA hierarchies and inform your customers of the upcoming changes as needed. The new Certificate Verification library (mozilla::pkix) was announced here: https://blog.mozilla.org/security/2014/04/24/exciting-updates-to-certificate-verification-in-gecko/ . Mozilla::pkix includes some changes in support of current best practices and policies, as listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Behavior_Changes . How to test: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Request_for_Testing .

Please respond with one of the following:

  • A) We have tested certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and found that the certificates in our CA hierarchies are not impacted by the changes introduced in mozilla::pkix.
  • B) We have found the following issues when testing certificates in our CA hierarchy with mozilla::pkix. <descriptions or Bugzilla bug numbers, related URLs and/or certificates>
  • C) We are testing certificates in our CA hierarchy with Mozilla's new Certificate Verification library, and plan to send Mozilla our results by <insert date here, must be before June 30, 2014>.

4) Check your certificate issuance to confirm that no new certificates will be issued with the problems listed here: https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix

Please respond with one of the following:

  • A) We have not and will not issue certificates with any of the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.
  • B) We have previously issued certificates with the following problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list the problems that needed to be fixed>. The last of those certificates expire <insert dates here, one date per problem>. We will not issue new certificates with the problems listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page as of this date: <date when your operations will be updated, no later than June 30, 2014>

5) Send Mozilla information about your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, as per Items #8, 9, and 10 of Mozilla's CA Certificate Inclusion Policy.

Please provide a URL to a web page or a Bugzilla Bug Number that lists all of your publicly disclosed subordinate CA certificates that chain up to certificates in Mozilla's CA program, and contains the required information according to section 10 of Mozilla's CA Certificate Inclusion Policy. If you decide to use the mozilla.org Bugzilla system to provide this information, then file the bug against the "CA Certificates" component of the "mozilla.org" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=mozilla.org&component=CA%20Certificates)

Additionally, please respond with one of the following:

  • A) All subordinate CA certificates chaining up to our certificates in Mozilla's CA program are either disclosed as requested above, or are technically constrained according to section 9 of Mozilla's CA Certificate Inclusion Policy.
  • B) We request an extension for the following specific subordinate CA certificates, because these subordinate CAs need more time to transition from their legacy systems to their new CA hierarchy: <list of issuer hash, issuer public key hash, and certificate serial number>. For each subordinate CA who needs to operate in their legacy design a little longer, the attached document explains the reason that continued operation is needed and their target date for resolution. <attach document(s) to response>

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

May 2014 Responses

CA Responses to May 2014 Communication

July 2013

Subject: Mozilla Communication: Action requested by August 16, 2013

Dear Certification Authority,

Mozilla’s CA Certificate Policy has been updated with a few important changes. This update was motivated by security concerns regarding ICANN granting applied-for new gTLD strings. Additionally, we want to make it very clear that there will be serious consequences if it is found that a CA has knowingly or intentionally mis-issued certificates chaining to trust anchors in Mozilla’s program.

Mozilla’s CA Certificate Program governs inclusion of root certificates in Network Security Services (NSS), a set of open source libraries designed to support cross-platform development of security-enabled client and server applications. The NSS root certificate store is not only used in Mozilla products such as the Firefox browser, but is also used by other companies in a variety of applications.

Please carefully review the following wiki page for information about the changes introduced in version 2.2 of Mozilla’s CA Certificate Policy. 

https://wiki.mozilla.org/CA:CertificatePolicyV2.2

This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by August 16, 2013, with your response to the following action items.

1) Update your CA operations and policies to include the CA/Browser Forum’s Baseline Requirement #11.1.4 regarding new gTLD domains, and subscribe to ICANN’s new gTLD Registry Agreement notification mailing list at: https://mm.icann.org/mailman/listinfo/gtldnotification

Please respond with one of the following:

  • A) No action required, because we have not and will not issue SSL certificates with internal or private domain names chaining up to root certificates that are included in Mozilla’s program.
  • B) We have issued or may issue SSL certificates with internal or private domain names that chain up to root certificates that are included in Mozilla’s program, so we are implementing Baseline Requirement #11.1.4, and will subscribe to ICANN’s notification service regarding applied-for-gTLD strings. We plan to have this completed by September 16, 2013.
  • C) We have already implemented Baseline Requirement #11.1.4, and have subscribed to ICANN’s notification service regarding applied-for-gTLD strings.

2) Review your CA operations and customers to ensure that there are no certificates chaining up to your trust anchors that are included in Mozilla’s program that may be used for MITM or “traffic management” of domain names or IP addresses that the certificate holder does not own or control. Mozilla’s CA Certificate Enforcement Policy has been updated to make it clear that Mozilla will not tolerate this use of publicly trusted certificates.

Please respond with:

  • “We have reviewed Mozilla’s updated CA Certificate Enforcement Policy and understand that knowing or intentional mis-issuance of a certificate is expressly against Mozilla’s CA Certificate Policy and could result in removal of all of our certificates from Mozilla’s products.”

3) Ensure that your CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current, including links to the CP/CPS documents, audit statements, and test websites. Mozilla will be adding a column to this spreadsheet to indicate the date of the most recent audit statement for each root certificate.

http://www.mozilla.org/projects/security/certs/included/index.html

Please respond with one of the following:

  • A) Our CA’s information in Mozilla’s spreadsheet of included root certificates is accurate and current for all of our included certificates.
  • B) Here is the current information for our certificates that are included in Mozilla’s program: <insert data here>

4) Complete the action items from Mozilla’s January CA Communication.

Please respond with one of the following:

  • A) Our recorded response to the January CA Communication is complete and correct.
  • B) We have the following updated status for our response to the January CA Communication: <insert data here>

5) Follow discussion about the changes to policy and code that Mozilla will be making in order to improve how revocation checking is handled in Firefox. Discussions will be held in the mozilla.dev.security.policy forum, and descriptions of the changes that will be considered for both policy and code will be provided here: https://wiki.mozilla.org/CA:ImprovingRevocation As part of this effort, Mozilla will be implementing a revocation list push mechanism in Firefox, which will push revocation lists of intermediate certificates to Firefox browsers on a regular basis, asynchronously and independently of any SSL site visit. This will improve security by ensuring the browser has a comprehensive list of revocations in a manner that is not likely to be blocked by a network attacker. More information will follow, and policy will be added soon to require CAs to send Mozilla revocation information. We encourage CAs to start participating in this effort now by sending Mozilla previously revoked intermediate certificates by submitting a bug report into the mozilla.org Bugzilla system, filed against the "CA Certificates" component of the "NSS" product. (https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates)

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module


July 2013 Responses

January 2013

Subject: Mozilla Communication: Action requested by January 31, 2013.

Dear Certification Authority,

This note requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. Please reply by January 31, 2013, with your response to these action items. A compiled list of CA responses to the following action items will be published.

1) Review the proposed changes to Mozilla’s CA Certificate Policy, and assess the impact of those changes to your CA operations.

Version 2.1 of Mozilla’s CA Certificate Policy is in final review, and will be ratified and published in Q1 of 2013. There are changes to the policy that may impact your current operations, so we encourage you to review the changes that are indicated in red or bold text here: http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/InclusionPolicy.html

There will be a transition period for CAs to bring existing customers into compliance with the new policy, as described here: https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy_Version_2.1

Please respond to this action item with one of the following:

  • a) The proposed updates to Mozilla’s CA Certificate Policy do not require further change to our CA operations, because our CA operations already comply with the proposed policy.
  • b) The proposed changes to Mozilla’s CA Certificate Policy impact our CA operations, but we will be able to complete the transition within the allotted time frame.
  • c) We will not be able to update our CA operations to comply with the proposed version 2.1 of Mozilla’s CA Certificate Policy within the allotted time frame, because <insert reason(s)>. We plan to meet the new requirements by <insert date>.

2) Confirm compliance with the CA/Browser Forum’s Baseline Requirements.

The CA/Browser Forum (http://www.cabforum.org) released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which became effective on July 1, 2012. It is our expectation that as of January 2013 CA issuance of SSL certificates will be audited against these Baseline Requirements as well as the acceptable audit criteria that are listed in Mozilla’s CA Certificate Policy.

Please respond to this action item with one of the following:

  • a) Our CA operations conform to the CA/Browser Forum’s Baseline Requirements for issuance of SSL certificates, and our next audit will include verification of this conformance.
  • b) Not applicable, because we do not issue SSL certificates.
  • c) We are working towards compliance with the CA/Browser Forum’s Baseline Requirements, but we need to complete <insert list of tasks>. We plan to have this completed by <insert date>.

3) Scan your certificate database for certificates that incorrectly have basicConstraints with the cA boolean set to true, or are incorrectly enabled with the keyCertSign Key Usage bit.

Due to the recent incident in which a mis-issued intermediate certificate was found (https://blog.mozilla.org/security/2013/01/03/revoking-trust-in-two-turktrust-certficates), we are concerned that CAs may have responded to our last communication based on their policies, rather than checking their certificate databases. Therefore, we request that you scan your certificate database and inform Mozilla if you find any un-expired intermediate certificates in your CA hierarchy that should not be trusted. In your reply, please attach all such intermediate certificates, even if you have already revoked them.

While you are scanning your certificate databases to ensure that all certificates with basicConstraints:CA:TRUE have been issued in accordance with your CPS, please also check for compliance with the following practices.

  • All certificates with basicConstraints:CA:TRUE have the basicConstraints marked critical.
  • All intermediate certificates with basicConstraints:CA:TRUE have cRLDistributionPoints containing a well-formed and compliant URL that returns a valid CRL.
  • All certificates that share a common issuer name contain unique serial numbers (independent of certificate expiration).
  • All end-entity certificates with RSA key sizes smaller than 2048 bits expire no later than December 2013.
  • Certificates are not issued with sequential serial numbers. If it is found that certificates have been issued with contiguous serial numbers, then the subject of those certificates must contain unpredictable data that is not under the control of the certificate subscriber.

Please respond to this action item with one of the following:

  • a) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.
  • b) We have scanned our certificate database, and confirm that there are no un-expired intermediate certificates in our CA hierarchy that should not be trusted. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.
  • c) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database to confirm that all of the non-expired certificates have been issued in accordance with the listed practices.
  • d) We have scanned our certificate database, and have found that the attached certificates should not be trusted. <Attach the certificates to the email>. We have also checked our certificate database regarding the listed practices and have found the following variances <list which practices are not met>. Problematic certificates will be revoked and replaced by <insert date>.

4) Deprecate issuance of SSL certificates containing a Reserved IP Address or Internal Server Name.

The CA/Browser Forum’s Baseline Requirements state: “As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016.”

This practice is being eliminated for security reasons, so we encourage all CAs to begin working with their customers to transition to alternative arrangements, and to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names as soon as possible rather than waiting until the deadline.

Please respond to this action item with one of the following:

  • a) We do not issue SSL certificates that chain up to a root certificate that is included in Mozilla's CA Certificate Program and that contain Reserved IP Addresses or Internal Server Names.
  • b) We plan to stop issuing SSL certificates containing Reserved IP Addresses or Internal Server Names by <insert date>.

5) For each root certificate or trust anchor you control that is included in Mozilla’s CA Certificate Program and has the SSL trust bit enabled by default, please provide a URL to a website (which may be a test site) whose SSL certificate chains up to it. We expect this website to endure for the lifetime of the root, or until you notify us of an alternative URL. The website does not need to support high traffic loads or have greater than 99% uptime.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

January 2013 Responses

CA Responses to January 2013 Communication -- Contains two spreadsheets: "Action Item Responses" and "Test Website URLs".

February 2012

Subject: Mozilla Communication: Action requested by March 2, 2012

Dear Certification Authority,

This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program.

Please reply by March 2, 2012, to confirm completion of the following actions or state when these actions will be completed.

1) Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control, regardless of whether it is in a closed and controlled environment or not. Please review all of the subordinate CAs that chain up to your root certificates in NSS to make sure that they cannot be used in this way. Any existing subordinate CAs that can be used for that purpose must be revoked and any corresponding HSMs destroyed as soon as possible, but no later than April 27, 2012. For each subordinate CA that is revoked, send me:

  • a) The certificate that signed the subCA. If it is a root certificate in NSS, then the root certificate's subject and SHA1 fingerprint.
  • b) The Serial Number of the revoked certificate.
  • c) The CRL that contains the serial number of the revoked certificate.

As a CA in Mozilla’s root program you are ultimately responsible for certificates issued by you and any intermediate CAs that chain up to your roots. After April 27, 2012, if it is found that a subordinate CA is being used for MITM, we will take action to mitigate, including and up to removing the corresponding root certificate. Based on Mozilla’s assessment, we may also remove any of your other root certificates, and root certificates from other organizations that cross-sign your certificates.

I am planning to publish a compiled list of CA responses to all of the action items in this communication. Therefore, I recommend responding to action item #1 with one of the following choices:

  • a) Does not apply, because we do not issue subCA certificates to third parties.
  • b) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.
  • c) We are reviewing all of our subCAs and will take the necessary action by <date>.
  • d) We have revoked such subCA certificates, and here is the requested information.
  • e) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM. (Note: This option was added after the communication was sent.)

2) If you issue subordinate CAs to third parties or your CP/CPS permits you to do so in the future, please add a statement to your CP/CPS committing that you will not issue a subordinate certificate that can be used for MITM or “traffic management” of domain names or IPs that the certificate holder does not legitimately own or control. Send me the URL to the updated document(s) and the impacted sections or page numbers.

3) Please scan all of your EV SSL certificates and revoke any that do not meet the EV requirements. This includes, but is not limited to maximum validity period of the certificate, subject naming, minimum key sizes, required extensions, and maximum expiration time of OCSP responses.

4) Certificates chaining to root certificates in Mozilla’s root program should not have MD5 algorithms or RSA keys shorter than 1024 bits long. Please scan the certificates chaining to your root certificates in NSS, and revoke any certificates that contain small key sizes or MD5 algorithms.

5) The CA/Browser Forum has released the "Baseline Requirements for the Issuance and Management of Publicly Trusted Certificates,” which is available here: http://www.cabforum.org/. Discussions are in progress in the mozilla.dev.security.policy forum to update Mozilla’s CA Certificate Policy to add a requirement that CAs also meet these baseline requirements for issuance of SSL/TLS certificates. Please contribute to the discussions in the mozilla.dev.security.policy forum, and update your operations and documentation as needed to meet the baseline requirements by the effective date of July 1, 2012.

The currently proposed updates to Mozilla’s CA Certificate Policy are here: http://www.mozilla.org/projects/security/certs/policy/WorkInProgress

Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

February 2012 Responses

CA Responses -- spreadsheet of the responses to the action items of the CA Communication that was sent on February 17, 2012.

Response Key:

  • IP = "In Progress"
  •  ? = I need further clarification on the response
  • N/A = "Not Applicable"
    • N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs.
    • N/A for Action #3 means that the CA is not issuing EV certs under the roots included in NSS.
  • Responses to action #1 can be one or more of the following. If option C is listed, there is also a date by which the CA plans to complete their investigation and provide further information.
    • A) Does not apply, because the CA does not have externally-operated subCAs chaining to roots in NSS.
    • B) SubCAs are technically and/or contractually restricted to only issue certificates to domains that they legitimately own or control, and they are specifically not allowed to use their subordinate certificates for the purpose of MITM.
    • C) The CA is reviewing all of their subCAs and will take the necessary action by <date>.
    • D) The CA has revoked such subCA certificates, and provided the requested information.
    • E) SubCAs are publicly disclosed to Mozilla, audited by a competent party (per Mozilla’s CA Certificate Policy) whose audit result has been publicly disclosed to Mozilla, and technically and/or contractually restricted to issue certificates in full compliance with Mozilla's CA Certificate Policy. SubCAs are specifically not allowed to use their subordinate certificates for the purpose of MITM.

September 2011

Subject: Mozilla Communication: Immediate action requested

Dear Certification Authority,

This note requests a set of immediate actions on your behalf, as a participant in the Mozilla root program.

Mozilla recently removed the DigiNotar root certificate in response to their failure to promptly detect, contain, and notify Mozilla of a security breach regarding their root and subordinate certificates (https://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up). If you ever have reason to suspect a security breach or mis-issuance has occurred at your CA or elsewhere, please contact security@mozilla.org immediately.

Please confirm completion of the following actions or state when these actions will be completed, and provide the requested information no later than September 16, 2011:

1) Audit your PKI and review your systems to check for intrusion or compromise. This includes all third party CAs and RAs.

2) Send a complete list of CA certificates from other roots in our program that your roots (including third party CAs and RAs) have cross-signed. A listing of all root certificates in Mozilla's products is here: http://www.mozilla.org/projects/security/certs/included

3) Confirm that multi-factor authentication is required for all accounts capable of directly causing certificate issuance.

4) Confirm that you have automatic blocks in place for high-profile domain names (including those targeted in the DigiNotar and Comodo attacks this year). Please further confirm your process for manually verifying such requests, when blocked.

5) For each external third party (CAs and RAs) that issues certificates or can directly cause the issuance of certificates within the hierarchy of the root certificate(s) that you have included in Mozilla products, either:

a) Implement technical controls to restrict issuance to a specific set of domain names which you have confirmed that the third party has registered or has been authorized to act for (e.g. RFC5280 x509 dNSName name constraints, marked critical)

OR

b) Send a complete list of all third parties along with links to each of their corresponding Certificate Policy and/or Certification Practice Statement and provide public attestation of their conformance to the stated verification requirements and other operational criteria by a competent independent party or parties with access to details of the subordinate CA's internal operations.

Each action requested above applies both to your root and to these third parties.

Participation in Mozilla's root program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your participation in this pursuit.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

April 2011

Subject: Mozilla Communication: Policy Discussions are in Progress that may Impact Your CA

Dear Certification Authority,

On behalf of Mozilla, I am contacting you in regards to three important items that we would like to bring to your attention.

1) The CA/Browser Forum has published a final draft of the document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates." We are now hosting a discussion about this document in the mozilla.dev.security.policy forum. For more information, see http://cabforum.org/. The document is here: http://cabforum.org/Baseline_Requirements_Draft_30b.pdf

Mozilla supports the CA/Browser Forum’s efforts in this area. After version 1.0 of the CA/Browser Forum’s Baseline Requirements document is published, we will have a discussion to add a requirement to the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) that CAs include the CA/Browser Forum Baseline Requirements in their policies, practices, and audits. Therefore, we urge you to review the draft of the Baseline Requirements, assessing the impact to your CA policies and practices, and participate in the current discussions about these requirements. The CA/Browser Forum has set the duration of this discussion to 45 days from April 11.

2) Mozilla has begun discussions about the Phase 2 items to be considered for updating the Mozilla CA Certificate Policy, https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. The current discussions are focused on RAs and Subordinate CAs. We recommend that you monitor and contribute to these discussions so that you are aware of how the potential changes to the Mozilla CA Certificate Policy may impact you.

3) As per previous communications, we will implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certificates. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.

We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

February 2011

Subject: Mozilla Communication: Version 2.0 of Mozilla CA Certificate Policy has been published

Dear Certification Authority,

As per my previous communication, Mozilla has ratified and published Version 2.0 of the Mozilla CA Certificate Policy.

The new policy is here: http://www.mozilla.org/projects/security/certs/policy/

A description of the changes to the policy is here: https://bugzilla.mozilla.org/show_bug.cgi?id=609945

There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than August 8, 2011.

Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes.

We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. Now that this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.

I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

January 2011

Subject: Mozilla Communication: Major Pending Update to Mozilla CA Certificate Policy

Dear Certification Authority,

As per my previous communication, Mozilla is preparing to update the Mozilla CA Certificate Policy. The forthcoming changes will come in multiple phases, and the first phase is nearly complete. Discussion about the first phase of changes has proceeded for several months in the mozilla.dev.security.policy forum. Version 2.0 of the policy, reflecting the first phase of updates, is now under final review. Mozilla expects it to be ratified by January 31, 2011.

There are changes in the policy that may impact your current operations. It is our expectation that all CAs with root certificates in Mozilla products will be in full compliance with Version 2.0 of the Mozilla CA Certificate Policy no later than April 30, 2011.

Please review the new policy and reply to me in email to let me know what changes you will need to make in order to be compliant, and when you expect to complete those changes.

The current policy (version 1.2) is here: http://www.mozilla.org/projects/security/certs/policy/

The new policy (version 2.0) is here: http://www.mozilla.org/projects/security/certs/policy/WorkInProgress/

A description of the changes to the policy is here: https://bugzilla.mozilla.org/show_bug.cgi?id=609945#c3

We encourage you to participate in the upcoming phases of updating the Mozilla CA Certificate policy. After this first round of updates is completed, we will begin the next phase by prioritizing the list in https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase. Then we will proceed to discuss and amend the Mozilla CA Certificate Policy to address each item. Each item (or group of related items) will potentially result in a dot (e.g. 2.1) update to the policy, and will be discussed and communicated in the mozilla.dev.security.policy forum.

I look forward to your prompt response regarding when you expect to be compliant with version 2.0 of the Mozilla CA Certificate Policy.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

October 2010

Subject: Mozilla Communication to CAs regarding Policy updates, October 2010

Dear Certification Authority,

On behalf of Mozilla, I am contacting you in regards to five important points that we would like to bring to your attention.

1) Mozilla has started a project to update the Mozilla CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/). The proposed changes may impact the operation of your root certificates that are included in NSS. Therefore, we request that all CAs participate in the discussions, which will be held in the Mozilla.dev.security.policy forum, http://www.mozilla.org/about/forums/#dev-security-policy. For information about the potential changes, please see https://wiki.mozilla.org/CA:CertPolicyUpdates.

2) As per the CA/Browser Forum’s Guidelines for EV Certs, CAs must provide an OCSP capability for end-entity certificates that are issued after Dec 31, 2010. Mozilla is considering technical ways to enforce this OCSP requirement such that if Firefox cannot obtain a valid response from the OCSP responder, then the certificate will not be given EV treatment. We are considering requiring the end-entity certificate to provide the OCSP URI in the AIA: https://bugzilla.mozilla.org/show_bug.cgi?id=585122#c23 Additionally, we urge all CAs to provide OCSP for all certs, even when they are not EV.

3) We expect that all new certificates contain randomness (preferably in the serial number), especially when using the SHA-1 hash function or an RSA key size smaller than 2048 bits. For more information, please see http://www.win.tue.nl/hashclash/rogue-ca/ section 5.2, “Validity period and serial number prediction”, and section 7, “Countermeasures.”

4) As per the NIST guidelines, it is our expectation that all CAs are transitioning from issuing certs with RSA key sizes smaller than 2048 bits. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.

5) We are planning to implement a code change to stop accepting MD5 as a hash algorithm for intermediate and end-entity certs. After June 30, 2011, software published by Mozilla will return an error when a certificate with an MD5-based signature is used. Mozilla will take this action earlier and at its sole discretion if necessary to keep our users safe. For more information, please see https://wiki.mozilla.org/CA:MD5and1024.

We look forward to your continued involvement and contributions to improving Mozilla’s CA Certificate Policy and practices.

Regards, Kathleen Wilson, Module Owner of Mozilla's CA Certificates Module

May 2010

Subject: Mozilla Communication: Acceptable Addresses for Domain Control Validation

Dear Certification Authority,

On behalf of Mozilla, I am contacting you in regards to some changes that we are proposing to make to Mozilla’s CA Certificate Policy.

Section 7 of the Mozilla CA Certificate Policy states: “for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf;”

Many CAs use an email challenge-response mechanism to verify that the SSL certificate subscriber owns/controls the domain to be included in the certificate. Some CAs allow applicants to select an address from a predetermined list to be used for this verification. Offering too many options for the email address prefix increases the risk of issuing a certificate to a subscriber who does not own/control the domain. Therefore, the list of email address prefixes should be limited.

Mozilla is proposing to restrict the set of verification addresses that may be used for domain validation to the following list or a subset of it. Mozilla’s goal is to strike a balance between flexibility and safety.

Accepted addresses for domain validation challenge-response email:

  • root@domain
  • admin@domain
  • administrator@domain
  • webmaster@domain
  • hostmaster@domain
  • Plus any address listed in the contact fields of the domain's WHOIS record.

We hope that this restriction, when implemented consistently across CAs, will not cause discrimination or hardship. We are seeking feedback on whether this is the case. We invite you to contribute your feedback to a discussion about this new restriction in the mozilla.dev.security.policy newsgroup and the corresponding dev-security-policy@lists.mozilla.org mailing list.

http://www.mozilla.org/community/developer-forums.html https://lists.mozilla.org/listinfo/dev-security-policy news://news.mozilla.org/mozilla.dev.security.policy

The discussion thread is called “Domain Control validation” and “Acceptable Addresses for Domain Control Validation”.

We have also added this information to our wiki page: https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs

We look forward to your contributions to this discussion.

Regards, Kathleen Wilson

November 2009

Subject: Mozilla Communication: SSL certificates issued to internal domain names

Dear Certification Authority,

On behalf of Mozilla I am contacting you in regards to root certificates that you currently have included by default in Mozilla products, such as the Firefox browser.

It has come to our attention that some Certification Authorities may have mistakenly issued SSL certificates to non-existent .int domain names. This appears to have happened because the .int domain may have been confused with internal domain names, and not all of the CAs and RAs may be aware that .int is an ICANN approved TLD.

Section 7 of Mozilla’s CA Certificate Policy states that CAs need to take “reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate.” There are different interpretations as to what this means in regards to internal domain names such as non-valid TLDs, hostnames, and IP addresses. However, there is consensus that there are problems associated with issuing certificates for servers on internal networks under the same CA hierarchy as certificates for servers on public networks. Mozilla is currently discussing whether the CA Certificate Policy should be updated to add more explicit requirements on this practice, or even to disallow it altogether.

In the light of the current situation, Mozilla requests that you take the following actions.

1) Perform an internal audit to look for certificates that have been issued within your CA hierarchy which have .int domain names in the Common Name and/or as DNS Names in the subjectAlternativeName. For each of these certificates, check to see if the certificate subscriber owns/controls that domain name, and revoke the certificate if they do not own/control that domain name.

2) Review your controls/procedures (both internally and your RAs) for correct identification of internal and external domain names and verification that subscribers own/control the domain name to be included in their certificate. Please refer to these documents: a) Section 7 of Mozilla’s CA Certificate Policy (http://www.mozilla.org/projects/security/certs/policy/) b) https://wiki.mozilla.org/CA:Recommended_Practices c) https://wiki.mozilla.org/CA:Problematic_Practices

Mozilla also recommends that you 1) Update your training procedures to ensure that all validation staff are aware of this situation. 2) Implement automated checks to signal a red flag for domains such as .int and null characters in the Common Name and subjectAlternativeName of certificates. 3) Maintain your own list of ICANN approved TLDs that are eligible to be used for domains in certificates issued within your CA hierarchy. If a new TLD is created by IANA, make an explicit decision whether or not to add the new TLD to your list. http://www.icann.org/en/registries/top-level-domains.htm

Mozilla strongly encourages you to take prompt action in order to ensure the continued security and trust-ability of your CA service.

Kathleen Wilson

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