Confirm, administrator
5,526
edits
Changes
Updated to match current process
== Disable a Root ==
Disabling a root is the act of turning off one or more of the three two trust bits (Websites, Email, Code Signing).
Reasons for disabling a root certificate may include, but are not limited to:
* Expired or Expiring CA
* Small modulus key length; [http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf NIST recommendations about phasing out 1024 bit roots] * Outdated signing key algorithm; e.g. MD2/MD5
* Transition/Rollover to new root completed
* Legacy, no longer in use
* 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 the a [httphttps://wwwbugzilla.mozilla.org/projects/security/securityenter_bug.cgi?product=NSS&component=CA%20Certificate%20Compliance&groups=crypto-bugscore-policy.html Mozilla Policy for Handling Security Bugssecurity secure bug filed in Bugzilla] should be followed.
The process for disabling a root in NSS is as follows:
# Any individual may initiate Initiate the request using the Mozilla project's :#* [httphttps://bugzilla.mozilla.org/ Bugzilla issue tracking system:]#* 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:
#** Product: NSS
#** Component: CA Certificate Root Program
#** Summary: Disable (CN or cert name) root cert
#** Description: Include the following information
#*** Value of the O (Organization) and OU (Organizational Unit) fields Subject/Issuer field values in the root certificate to be changed#*** The SHA256 Fingerprint of 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)
#*** Which trust bits are to be turned off
#*** Reason for requesting this change
#** 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 changing the trust bits of 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[[Modules/Activities#CA_Certificates|CA Certificates 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)
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits
#* Technical assistance may be requested
# 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]
# 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 makes the changes in 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 changedrequests code review.
#* 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.
