CA:MaintenanceAndEnforcement

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

Maintaining Confidence in Root Certificates

Mozilla's efforts to maintain confidence in root certificates include:

1. Carefully reviewing CA applications for root inclusion.
   • A Mozilla representative checks the CA's CP/CPS documentation for
     • compliance with Mozilla's CA Certificate Policy,
     • compliance with 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 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 Mozilla's CA Certificate Policy.
2. Keeping a record of current audit statements for each CA.
   • Spreadsheet of included root certs and their corresponding documentation and current audit statements
   • Mozilla's CA Certificate Maintenance Policy states that CAs must provide current audit statements.
3. Updating policies and practices as issues are found/realized, communicating updates and recommendations to CAs, and tracking CA responses to communications.
   • CA Communications
   • https://wiki.mozilla.org/CA:Communications#Responses
   • If a CA does not provide updated audit statements and does not promptly respond to Mozilla's communications, then action will be taken as described in Mozilla's CA Certificate Enforcement Policy.
4. When a potential certificate mis-issuance is noticed by anyone, they should report it according to Mozilla's Security Policy, and people from the security group work together to determine and take appropriate action, by considering the criteria listed below.

When a security threat or potential certificate mis-issuance arises with a CA in Mozilla's program we consider the impact/risk to the end-users to decide on the action to take. The following considerations are taken into account:

• Magnitude of the threat
  • How can the threat or mis-issuance be used by a hacker to put end-users at risk?
  • Has all appropriate action been taken by the CA to prevent further impact to end-users?
  • What additional actions does Mozilla need to take to protect end-users from the threat or mis-issuance?
    • How will end-users be impacted by Mozilla actions?
    • Can Mozilla take a different action that will protect end-users, but confine noticeable impact to the smallest group possible?
    • Will Mozilla's actions have a worse impact on end-users than the current threat or mis-issuance?
• CA behavior
  • Did the CA notice the error and take appropriate action in a timely manner?
    • Was the threat or error properly contained?
  • Did the CA notice the hacker intrusion and take appropriate action in a timely manner?
    • Were the CA's defense mechanisms current and sufficient?
    • Was the intrusion appropriately contained?
  • Was the CA's behavior reckless?
  • Did the CA try to cover up the mistake/threat rather than follow Mozilla's Security Policy?

We depend on audit statements to confirm that CAs are continuing to maintain their operations in conformance with Mozilla's CA Certificate Policy. When reviewing an audit statement, if the statement is provided on the webtrust.org website or an known auditor's website or on a government certified website, then I (Kathleen) assume the statement is legitimate, and I review the statement to make sure it covers the root certs that are included in Mozilla's program. If the audit statement is provided directly by the CA, then I first check the legitimacy of the auditor, and then I send email directly to the auditor to confirm the authenticity of the audit statement. To check the legitimacy of the auditor, if it is not someone I have previously verified, I check the webtrust.org website or the government's website to see if the auditor is accredited. If the auditor claims to be AICPA/CICA/CISA accredited and I don't recognize them or they are not listed on a trusted website as being accredited, then I will send email to a representative of CICA or CISA, depending on the audit credentials that are being claimed.

Risks to Consumers

When a hacker is in possession of a mis-issued certificate, they 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.
• Re-direct users to a fake site -- Users on a compromised network could be directed to sites using a fraudulent certificate and mistake them for the legitimate sites.
  • In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.
• Sign malicious code and make it look like it came from a valid organization, such as the end-user's bank.

If a user visits an SSL site presenting a fraudulent certificate, there will be no obvious sign of a problem and the connection will appear to be secure.

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.
• Downloading malware if they believe it’s coming from a trusted site. The malware can contain malicious content or software.

There is currently no complete technical solution that allows browsers to detect mis-issued certificates, so we usually learn about mis-issued certificates from an inquisitive user, a CA, or another browser vendor. Once we learn about a mis-issued certificate we do a software update to add the relevant certificate(s) to a blacklist.

It is important to note that possession of the mis-issued certificate alone does not allow an attacker to do anything. They also need some control of 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).

Actions taken to Actively Distrust a Root Certificate in NSS