CA/Communications: Difference between revisions
m (→Responses) |
|||
| Line 49: | Line 49: | ||
Response Key: | Response Key: | ||
* IP = "In Progress" | * IP = "In Progress" | ||
* ? = I need further clarification on the response | * ? = I need further clarification on the response | ||
| Line 56: | Line 54: | ||
** N/A for Action #2 means that the CP/CPS does not allow for externally-operated subCAs. | ** 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. | ** 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) 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. | |||
=== September 8, 2011 === | === September 8, 2011 === | ||
Revision as of 22:50, 7 March 2012
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.
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) 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.
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