MozillaWiki

CA/Certificate Change Process: Difference between revisions

Page Discussion

CA/Certificate Change Process (view source)

Revision as of 17:22, 13 November 2023

4,766 bytes removed ,  13 November 2023
→‎Remove or Disable a Root: Updated with information about security incident reporting
(→‎Remove or Disable a Root: Updated with information about security incident reporting)
 
(25 intermediate revisions by 3 users not shown)
Line 6: Line 6:


* Security Compromise
* Security Compromise
* Add a Trust Bit (one of Websites, Email Code Signing)
* Add a Trust Bit (one of Websites, Email)
* Enable EV
* Enable EV
* Disable a Root (turn off one or more of the trust bits)
* Disable a Root (turn off one or more of the trust bits)
Line 13: Line 13:
== Security Compromise ==
== Security Compromise ==


When a serious security concern is noticed, such as a major root compromise, it 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.
When a serious security concern is noticed, such as a root compromise, it should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug should be filed in Bugzilla].
 
To report a concern about certificates being issued by a CA in Mozilla's Program:
 
* https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Certificate%20Compliance&version=other
 
Open CA Mis-Issuance and other compliance bugs: https://wiki.mozilla.org/CA/Incident_Dashboard


== Add a Trust Bit ==
== Add a Trust Bit ==


When a root certificate is included in NSS, one or more of the three trust bits (websites, email, code signing) are enabled. It is common for a CA to request inclusion with a subset of the trust bits enabled, and then later request that an additional trust bit be enabled. The following steps outline how a CA may request to enable additional trust bits for a root certificate that is included in NSS.
When a root certificate is included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS], one or more of the trust bits (websites, email) are enabled. It is common for a CA to request inclusion with one of the trust bits enabled, and then later request that the other trust bit be enabled. The following steps outline how a CA may request to enable an additional trust bit for a root certificate that is included in NSS.


# Do some initial preparations before you formally submit a request:  
# Do some initial preparations before you formally submit a request:  
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy], especially section 7.   
#* Update the CP/CPS to reflect the policies for the additional trust bits, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy].   
#* Review the [[CA:Recommended_Practices|Recommended Practices]] and [[CA:Problematic_Practices|Potentially Problematic Practices]].
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].
#* Have the annual audit cover the updated CP/CPS.
#* Have the annual audit cover the updated CP/CPS.
#* Make sure that the audit meets the requirements stated in the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy.]
#* Make sure that the audit and audit statements meet the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].
# Once you are ready, formally submit your request using the Mozilla project's [http://bugzilla.mozilla.org/ Bugzilla issue tracking system:]
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]
#* Click on the "Create a new bug report" link in [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request|CA:How_to_apply]].  
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]].  
#* Set the bug summary to "Enable trust bits for <name of your root>".
#* Set the bug summary to "Enable trust bits for <name of your root>".
#* In the bug description, include a reference to the original root-inclusion bug number.
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].
#* In the bug description, include links to the updated CP/CPS and the updated audit.
# 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]].
# The request will go through the [[ CA:How_to_apply#Information_gathering_and_verification|Information Gathering and Verification]], [[CA:How_to_apply#Public_discussion|Public Discussion]], and [[CA:How_to_apply#Inclusion|Inclusion]] phases as described in [[CA:How_to_apply|CA:How_to_apply]].


== Enable EV ==
== Enable EV ==


The following steps outline the procedure for a CA to request that Extended Validation (EV) be enabled for a root certificate that is currently included in NSS.
The following steps outline the procedure for a CA to request that Extended Validation (EV) treatment be enabled for a root certificate that is currently included in [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS].


# Do some initial preparations before you formally submit a request:  
# Do some initial preparations before you formally submit a request:  
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy] as well as the [http://www.cabforum.org/Guidelines_v1_2.pdf EV SSL Certificate Guidelines Version 1.2] that are posted on the CA/Browser Forum website.
#* Update the CP/CPS to reflect the EV policies, and make sure that the additions to the CP/CPS follow [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy Mozilla's Root Store Policy] as well as the [https://cabforum.org/extended-validation/ CA/Browser Forum's EV SSL Certificate Guidelines].  
#* See the [[CA:Recommended_Practices|Recommended Practices]] and [[CA:Problematic_Practices|Potentially Problematic Practices]].
#* Review [[CA/Required_or_Recommended_Practices|Required Practices]] and [[CA/Forbidden_or_Problematic_Practices|Forbidden Practices]].
#* Complete a WebTrust EV audit that meets the requirements stated in the [http://www.mozilla.org/projects/security/certs/policy/ Mozilla CA Certificate Policy.]
#* Complete an EV audit that meets the requirements stated in [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits Mozilla's Root Store Policy].
# Once you are ready, formally submit your request using the Mozilla project's [http://bugzilla.mozilla.org/ Bugzilla issue tracking system:]
# Once you are ready, formally [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submit your request]]
#* Click on the "Create a new bug report" link in [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request|CA:How_to_apply]].  
#* Click on the "Create a new bug report" link in [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|Application Instructions]].  
#* Set the bug summary to "Enable EV for <name of your root>".
#* Set the bug summary to "Enable EV for <name of your root>"..
#* In the bug description, include a reference to the original root-inclusion bug number.
#* Provide all of the required information by creating a [[CA/Information_Checklist#Create_a_Root_Inclusion_Case|Root Inclusion Case in the CCADB]].
#* In the bug description, include links to the updated CP/CPS and the WebTrust EV audit.
#* Run the [[PSM:EV_Testing_Easy_Version#EV-Readiness_Check|EV-Readiness Check]].
# The request will go through the [[ CA:How_to_apply#Information_gathering_and_verification|Information Gathering and Verification]], [[CA:How_to_apply#Public_discussion|Public Discussion]], and [[CA:How_to_apply#Inclusion|Inclusion]] phases as described in [[CA:How_to_apply|CA:How_to_apply]]
# 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]].
 
== Disable a Root ==


Disabling a root is the act of turning off one or more of the three trust bits (Websites, Email, Code Signing).
== Remove or Disable a Root ==
Disabling a Root means one or more of the following:
* Turn off trust bits (Websites, Email)
* Turn off EV Treatment
* Distrust certificates issued after a certain date (Distrust for TLS After, Distrust for S/MIME After)


Reasons for disabling a root certificate may include, but are not limited to:
Reasons for removing or disabling a root certificate may include:
* [https://wiki.mozilla.org/CA/Vulnerability_Disclosure Security Compromise]
* Expired or Expiring CA  
* 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]
* Small modulus key length
* Outdated signing key algorithm; e.g. MD2/MD5
* Outdated signing key algorithm
* Transition/Rollover to new root completed  
* Transition/Rollover to new root completed  
* Legacy, no longer in use  
* Legacy, no longer in use  
* No recent audit  
* 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 [http://www.mozilla.org/projects/security/security-bugs-policy.html Mozilla Policy for Handling Security Bugs] should be followed.
'''Important:''' Root changes that are motivated by a serious security concern such as a root compromise should be treated as a security-sensitive bug, and a [https://bugzilla.mozilla.org/enter_bug.cgi?product=CA%20Program&component=CA%20Security%20Vulnerability&groups=ca-program-security secure bug filed in Bugzilla].


The process for disabling a root in NSS is as follows:
Otherwise, the ordinary or usual process for removing or disabling a root in NSS is as follows:
# Any individual may initiate the request using the Mozilla project's [http://bugzilla.mozilla.org/ Bugzilla issue tracking system:]
# Initiate the request:
#* File a bug in Bugzilla with the following information:
#* [https://bugzilla.mozilla.org/enter_bug.cgi?&component=CA%20Certificate%20Root%20Program&product=CA%20Program&short_desc=Remove%20%5Byour%20CA%27s%20name%5D%20root%20certificate%28s%29 File a bug in Bugzilla] with the following information:
#** Product: mozilla.org
#** Product: CA Program
#** Component: CA Certificates
#** Component: CA Certificate Root Program
#** Summary: Disable (CN or cert name) root cert
#** Summary should be one of:  
#*** Remove <CN or cert name> root cert
#*** Turn off Trust Bit(s) for <CN or cert name> root cert
#*** Turn off EV Treatment for <CN or cert name> root cert
#*** Set Distrust After for <CN or cert name> root cert  
#** Description: Include the following information  
#** Description: Include the following information  
#*** Value of the O (Organization) and OU (Organizational Unit) fields in the root certificate to be changed
#*** Subject/Issuer field values in the root certificate to be changed
#*** The certificate Common Name and or Certificate Name
#*** SHA256 Fingerprint of the certificate to be changed
#*** If needed, other information to clearly identify which root is to be changed (eg SHA1 Fingerprint)
#*** Specify the change to be made. e.g. if the root is to be removed, or which trust bits are to be turned off, or the distrust-after dates
#*** 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, rather than just remove 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
#*** Reason for requesting this change
#*** Impact that the change may have on Mozilla users
#*** Impact that the change 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 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 changing the trust bits of the root.  
#** 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.  
#* 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 bug will be assigned to the Mozilla representative who is appointed to evaluate the request. This will usually be the [[Modules/Activities#CA_Certificates|CA Certificates Module Owner]].
# The Mozilla representative will ensure the necessary information has been provided.
# The Mozilla representative will ensure the necessary information has been provided.
#* Options should be identified  
#* Options should be identified  
#** Which trust bits to unset (Websites, Email, Code Signing)
#** Which trust bits to unset (Websites, Email)
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits
#** Whether the root certificate should be removed from NSS instead of unsetting trust bits
#* Technical assistance may be requested
#* Technical assistance may be requested
Line 87: Line 99:
#** Two Mozilla staff members, if the CA is not in agreement.
#** Two Mozilla staff members, if the CA is not in agreement.
# The Mozilla representative will deliver any preliminary decisions
# 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]
#* 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] or the '''[https://wiki.mozilla.org/CA/Vulnerability_Disclosure root program's security incident reporting process]'''.
# 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 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 whom the bug is assigned to 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
# 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.
#* 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 makes the changes in an [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS NSS] branch, and requests code review.
#* A Mozilla representative checks the changes into the NSS store, and marks the bug RESOLVED FIXED.
#* A Mozilla representative commits the changes into NSS, 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]
#* A Mozilla representative confirms the changes in Firefox Nightly, then updates the corresponding records in the [https://www.ccadb.org/ CCADB].
#* 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 ==
 
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: mozilla.org
#** Component: CA Certificates
#** 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 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 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.
#* 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.
Bwilson
Confirmed users
518

edits

Retrieved from "https://wiki.mozilla.org/Special:MobileDiff/199464...1248939"