=== Remove a Root ===
text hereReasons 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 * Outdated signing key algorithm * Transition/Rollover to new root completed * Legacy, no longer in use * Previously deprecated Note: For some legacy root certificates it may be better to leave the root in NSS with the email trust bit enabled, so that S/MIME will work without error on older email messages. The Disable a Root section above explains how to request that specific trust bits be turned off for a root certificate. The process for disabling a root in NSS is as follows:# Initiate the request#* File a bug in Bugzilla with the following information:#** Product: mozilla.org#** Component: CA Certificates#** Summary: Disable (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 Fingerprint)#*** Which trust bits are to be turned off#*** Reason for requesting this change#*** Impact that the change may have on Mozilla users#** An authoritative representative of the CA must approve the change.# 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 #** Which Trust Bits to unset (Websites, Email, Code Signing)#** Versus complete removal of the root cert from NSS#* Technical assistance may be requested#* Additional information may be requested of CA and other parties#* The Mozilla representative should confirm that a qualified representative of the CA has either requested or approved the change.# The Mozilla representative 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 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 changes 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 which Trust Bits to unset#* Any other options or actions as decided# Implementation#* If the resulting decision is to 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.#* 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.# 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.
