Personal tools

CA:Communications

From MozillaWiki

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.

Contents

July 30, 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 10, 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 17, 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

Responses

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

Disclaimer: Please let me know if you notice an error in the data in this spreadsheet, and I will be happy to address it.

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 8, 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 15, 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 8, 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 13, 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 11, 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 12, 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 23, 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