136
edits
Changes
Review and many edits
#** compliance with [https://wiki.mozilla.org/CA/Required_or_Recommended_Practices Mozilla's Recommended Practices] (if issues are noted, they are discussed to determine of the CA takes appropriate measures to protect end-users), and
#** avoidance of [https://wiki.mozilla.org/CA/Forbidden_or_Problematic_Practices Mozilla's list of Potentially Problematic Practices] (if found, further questions and discussion follow to evaluate if the CA's measures are sufficient to protect end-users).
#* A Mozilla representative confirms that the CA has been audited as per [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ #31-audits Mozilla's Root Store Policy.]
# Keeping a record of current audit statements for each CA.
#* [https://wiki.mozilla.org/CA/IncludedCertificates Table Link to the list of included root certs and their corresponding documentation and current audit statements].#* [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#313-audit-parameters Mozilla's Root Store Policy] states that CAs must conduct period-of-time audits and provide updated publicly-available audit documentation no less frequently than annually..
# Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.
#* [https://github.com/mozilla/pkipolicy/issues Issues list for Mozilla’s Root Store Policy]
#* [https://wiki.mozilla.org/CA/Communications CA Communications]
#* If a CA does not respond to Mozilla's communications within the timeframe specified in the communication or does not provide a copy of its annual audit statement within 15 months of the end of its previous annual audit period, then Mozilla may take action up to and including [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#73-removals removal of the root(s) from the program].
# When a potential certificate mis-issuance is noticed by anyone, they should report it by [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance creating a bug in the CA Certificate Mis-issuance component]. More information on filing a security-sensitive bug can be found in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy.]
** Did the CA try to cover up the mistake/threat rather than follow [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Security Policy?]
Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Root Store Policy]. Statements obtained from an auditor are assumed legitimate. Audit statements provided by a CA are verified for legitimacy with the auditor. The
qualifications of any auditors not previously approved by Mozilla are reviewed before an audit statement is accepted. Auditor qualifications are reviewed using the webtrust.org website or an appropriate government website. If the auditor claims to be AICPA/CICA/CISA accredited, but the
auditor is not approved by Mozilla and not listed on a trusted website as accredited, then Mozilla will verify the auditor's qualifications with a representative of CICA or CISA, as appropriate.
= Risks to Consumers =
Possession of a mis-issued certificate alone does not allow an attacker to do anything. The attacker also needs some control over the victim's network connection. This means that the most likely attacks are either very localized (shared public WiFi, local network compromise) or very broad (governments). An attacker armed with a fraudulent certificate and an ability to control their victim’s network could impersonate websites in a way that would be undetectable to most users. The end users could be deceived into revealing personal information such as usernames and passwords, or downloading malware (containing malicious content or software) if they believe it’s coming from a trusted site.
An attacker armed with a fraudulent SSL certificate and an ability to control their victim’s network can:
= Potential Problems, Prevention, Response=
While CA incidents have differing levels of seriousnessseverity, there are some components which every CA should be able to avoid which are red flags for Mozilla in terms of a continued trust relationship, and which would lead to an investigation. They are:
* Deliberate violation of Mozilla or other applicable policy
* Lying or deception
* Concealing or failing to disclose the full extent of a problem
Mozilla will also assess how concerned we are about an issue in part based on how the CA reacts to that issue, and previous ones. In incident response, Mozilla is looking for the following factors:
* A CA takes responsibility for their own actions.
* Root cause analysis is performed.
* Any questions posed, by anyone, are answered quickly and in detail.
* A reasonably-detailed [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report] is made public on what happened, why, and how things have changed to make sure it won’t happen again.
The following is an enumeration of some of the different kinds of problems that may occur, and what our prevention or immediate response to those problems should be, as long as the CA is demonstrating responsibility and integrity as described above. This is not about meting out punishment, and is not intended to be punitive. Rather, when there is evidence of one of the problems below with a certificate chaining up to a CA in Mozilla's CA Certificate program, we need to take the necessary steps to keep users safe.
'''Problem:''' CA mis-issued a small number of SSL certificates that they can enumerate
* Immediate Minimum Response: Open a CA compliance bug and request an [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report incident report].
* Depending on the situation, also consider adding the certificates to OneCRL.
'''Problem:''' CA failed to supply proper audit documentation, or audit report contains numerous and/or serious qualifications
* Immediate Minimum Response: File a [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Mis-Issuance CA compliance ] bug and request that the CA respond with remediation plans.
* Depending on the situation, also consider requiring the CA to undergo new period-of-time audits as soon as the problems have been resolved. If the same problems are included on the new audit reports, they must state the dates on which the problems were resolved.
= Ongoing Issues =
In addition to evaluating the severity of a specific incident, Mozilla considers the totality of known issues and patterns of behavior in a CAs CA's response to those issues. When Mozilla believes that sufficient evidence is availableto establish an ongoing pattern of neglect or incompetence, an Issues List may be created. Mozilla will compile the facts of known problems of a particular CA and create a wiki page listing them. Mozilla may then ask the community to consider a response to the combined set of issues based on the overall perceived riskto users. This response typically involves distrust of the CAs currently included roots, or requiring the CA to undergo more frequent audits until the Mozilla community’s trust in the CA has been adequately restored.
'''Issues Lists'''
= Actively Distrusting a Certificate =
[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] and the [https://cabforum.org/ CA/Browser Forum's ] Baseline Requirements list some of the reasons why a certificate should be revoked. For the common revocations, CRL and OCSP revocation checking are sufficient. However, in extenuating circumstances, such as those listed above, Mozilla may take additional action to protect users by actively distrusting a certificate.
The steps to actively distrust a certificate are as follows.
#* As per [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs] a security concern may be reported by sending email to [mailto:security@mozilla.org security@mozilla.org] or by [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Security&bug_severity=critical filing a bug.]
# Decide on course of action
#* See [[https://wiki.mozilla.org/CA:MaintenanceAndEnforcement/Maintenance_and_Enforcement#Potential_Problems.2C_Prevention.2C_Response | Immediate Minimum Responses]] above.
#* Depending on the situation, discussion to determine the course of action may occur in private security group email list and/or in the public mozilla.dev.security.policy forum.
#* The bug will be updated to indicate corresponding decisions.
