# The request will go through the [[CA/Application_Verification#Information_Verification|Information Verification]], [[CA/Application_Verification#Detailed_Review|Detailed Review]], [[CA/Application_Verification#Public_Discussion|Public Discussion]], and [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|Inclusion]] phases as described in [[CA/Application_Process#Process_Overview|Application Process Overview]].
== Remove or Disable a Root == Disabling a root is the act of turning off one or more of the two trust bits (Websites, Email). Reasons for removing or disabling a root certificate may include, but are not limited to:* Security Compromise
* Expired or Expiring CA
* Small modulus key length
* No recent audit
'''Important:''' Root changes that are motivated by a serious security concern such as a major root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&groups=crypto-core-security secure bug filed in Bugzilla].
The process for removing or disabling a root in NSS is as follows:
# Initiate the request:
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=NSS&bug_severity=enhancement&short_desc=Add%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:
#*** Subject/Issuer field values in the root certificate to be changed
#*** SHA256 Fingerprint of the certificate to be changed
#*** Which Specify if the root is to be removed, or which trust bits are to be turned off#**** Consideration: For a serious situation, it might be better to disable the trust bits of that root by default, rather than just removing the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for TLS in Firefox unless a user specifically turned on the websites trust bit for it.
#*** Reason for requesting this change
#*** Impact that the change may have on Mozilla users
#* A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
#* A Mozilla representative confirms the changes in Firefox Nightly.
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.
# Notification
#* The CA is responsible for providing appropriate notification to users who may be impacted by the change.
#* For [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests the security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.
== Remove a Root ==
''Kathleen: I’ve been thinking about the result of an included root being caught in something serious, such as a MITM attack. If that does happen, then it might be better to disable the trust bits of that root by default, rather than just removing the root. If the root is removed, it could potentially be signed by another root that is included in NSS. However, if we disable the trust bits by default, then that root could not be used again for SSL in Firefox unless a user specifically turned on the websites trust bit for it.''
Reasons for removing a root certificate may include, but are not limited to:
* Security Compromise
** Root removals that are motivated by a serious security concern such as a major root compromise should be treated as a security-sensitive bug, and the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] should be followed.
* Expired or Expiring CA
* Small modulus key length (e.g. 1024-bit or smaller)
* Outdated signing key algorithm (e.g. MD2 or MD5)
* Transition/Rollover to new root completed
* Legacy, no longer in use
* No recent audit
* Previously deprecated
Note: For some root certificates it may be better to turn off the websites trust bit and leave one or both of the email and code singing trust bits enabled. The [[CA:Root_Change_Process#Disable_a_Root|Disable a Root]] section above explains how to request that specific trust bits be turned off for a root certificate.
The process for removing a root from NSS is as follows:
# Any individual may initiate the request using the Mozilla project's [http://bugzilla.mozilla.org/ Bugzilla issue tracking system:]
#* File a bug in Bugzilla with the following information:
#** Product: NSS
#** Component: CA Certificate Root Program
#** Summary: Remove (CN or cert name) root cert
#** Description: Include the following information
#*** Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
#*** The certificate Common Name and or Certificate Name
#*** If needed, other information to clearly identify which root is to be changed (eg SHA1 or SHA256 Fingerprint)
#*** Reason for requesting that the root be removed
#*** Impact that removing the root may have on Mozilla users
#* The bug may be marked as security-sensitive. Security-sensitive bugs can be viewed only by a select set of Bugzilla users, not by the general public.
#** The security module owner works with the bug reporter and others to determine when the bug should be opened to public view. For example, this might be done after release of a security update removing the root.
#* In most situations an authoritative representative of the CA must request or approve the change. Mozilla reserves the right to approve the change without the consent of the CA.
# The bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the standing module owner.
# The Mozilla representative will ensure the necessary information has been provided.
#* Options should be identified
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits
#* Technical assistance may be requested
#* Additional information may be requested of CA and other parties
#* The Mozilla representative must confirm that a qualified representative has approved the change. A qualified representative is either
#** The known representative of the CA, or
#** Two Mozilla staff members, if the CA is not in agreement.
# The Mozilla representative whom the bug is assigned to will deliver any preliminary decisions
#* It may be necessary to treat the bug as a sensitive security issue and follow the [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs]
# The Mozilla representative whom the bug is assigned to will start a public discussion in the mozilla.dev.security.policy newsgroup.
#* Outline is presented, references to full bug provided
#* Deadline for discussion is set
#* [http://www.mozilla.org/projects/security/security-bugs-policy.html Security-sensitive] requests for root removals would be discussed primarily within the (closed) Mozilla security group. However others could be added to the discussion by explicitly cc-ing them on the bug.
# The Mozilla representative will summarize the discussion and communicate the decisions in the bug.
#* Decision about whether or not to remove the root certificate
#* Any other options or actions as decided
# Implementation
#* If the resulting decision is to remove or change the root certificate, the Mozilla representative will create a corresponding NSS bug to make the actual changes in NSS, and mark that bug as blocking the original change request.
#* A Mozilla representative creates a test build of NSS with the change to the root certificate, and attaches nssckbi.dll to the bug. A representative of the CA or of Mozilla must download this, drop it into a copy of Firefox and/or Thunderbird and confirm (by adding a comment in the bug) that the certificate has been correctly changed or removed.
#* A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
#* For security-sensitive bugs, the security update will proceed as described in [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla's Policy for Handling Security Bugs]
#* For non-security-sensitive requests, some time after the bug is marked as RESOLVED FIXED, various Mozilla products will move to using a version of NSS which contains the change. This process is mostly under the control of the release drivers for those products.
