CA/Maintenance and Enforcement: Difference between revisions

# Carefully reviewing CA applications for root inclusion.

#* A Mozilla representative checks the CA's CP/CPS documentation for

#** 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/ Mozilla's Root Store Policy.]

#* [https://wiki.mozilla.org/CA/IncludedCertificates Table 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..

# 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.]

Mozilla relies on audit statements submitted by either the CA or an auditor to confirm a CA's compliance with Mozilla's 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.

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 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:

* Impersonate a valid website -- Present a fake website that looks like a valid website, and make the browser believe it is the real version of the website, because the browser finds that the SSL certificate of the fake site is valid.

While CA incidents have differing levels of seriousness, 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:

* A reasonably-detailed [https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report report] is made public on what happened, why, and how things have changed to make sure it won’t happen again.

 

 

 

'''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 [CA/Responding_To_An_Incident#Incident_Report incident report].

* Depending on the situation, also consider adding the certificates to OneCRL.

* 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 intermediate CA certificate(s) to OneCRL, distrusting the root certificate that the mis-issued certificates chain up to, or all of the root certificates owned by that CA.

* Immediate Minimum Response: File a CA compliance bug and request that the CA respond with remediation plans.

= 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 response to those issues. When Mozilla believes that sufficient evidence is available, 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 set of issues based on the overall risk. 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'''

* https://wiki.mozilla.org/CA:PROCERT_Issues

* https://wiki.mozilla.org/CA:Symantec_Issues

* https://wiki.mozilla.org/CA:WoSign_Issues

* https://wiki.mozilla.org/CA:Visa_Issues

[https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy] and the 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.

#* See [[https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#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.

#* If it is determined that a certificate needs to be actively distrusted in NSS, then the following will also be done.

#** Update NSS by adding a new entry to the built-in root cert list, to take away trust instead of giving trust. This is done with a separate "distrust" flag, and is called '''Active Distrust'''. Active Distrust can be done for any root, intermediate, or leaf certificate. Active Distrust does not require the entire certificate, because it may be done with a combination of the certificate Serial Number and Issuer. Note: The built-in cert list has two types of entries; cert entries and trust entries. A (dis)trust entry can be added without adding a corresponding cert entry.

#* Add test to cert.sh for the ongoing test of the Active Distrust. At minimum, need the intermediate cert for this test. Preferable to also have a leaf cert, which may have been provided when the compromised cert was reported; otherwise would need to request from the CA.

#* Depending on the timing and the urgency of the patch, the update may be done either as part of regularly scheduled [https://wiki.mozilla.org/Releases Mozilla releases,] or as a chemspill update (an off-schedule release that addresses live security vulnerabilities). Some Linux users of Firefox use their OS version of NSS, so they would have to make sure that they pick up the new version of NSS.

#* Announcement in mozilla.dev.security.policy

** Possible Solutions: {{Bug|712615}}, {{Bug|643982}}, or make an announcement that the root will be distrusted on such a date, allowing a small transition time for websites to update their SSL certs before before the Firefox chemspill update is released.