Confirm, administrator
5,526
edits
Changes
cleanup
The internet secure communications system requires Certification Authorities (CAs) - parties trusted to attest to the identity of websites. Mozilla products ship a default list of CA certificates, which may change with each security patch or new version of the product. The following pages explain how the default list of CA certificates is managed.
=Who May Apply =An official representative of the CA must make the formal request for inclusion or update of their CA's root certificates. If you would like to see a particular root certificate included in Mozilla products, then please contact the CA who operates that root certificate. CAs must carefully consider whether their root certificate needs to be [[CA/Included_Certificates|directly included in Mozilla's root store]] or if it would be better to be a [[CA/Intermediate_Certificates|subordinate CA of an already-included CA]]. If a CA controls all the domains that use their root certificate, then they probably do not meet the criteria for inclusion in Mozilla's root store. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] states: "We will determine which CA certificates are included in software products distributed by Mozilla, based on the benefits and risks of such inclusion to typical users of those products." With ALL affected domains under your control, your root certificate would not seem to create a benefit for typical Mozilla users, only for users of your services. Perhaps a better alternative is to be a [[CA/Intermediate_Certificates|subordinate CA]] of a CA who is already [[CA/Included_Certificates|included in Mozilla's root store]]. According to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy]: "We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software products." It is the CA's responsibility to explain why their root needs to be included in NSS and explain how the inclusion will benefit typical Mozilla users. = Process Overview ==
It can take as long as [[CA:How_to_apply#Timeline | two years]] for a new CA to make it from one end of the process to the other. If the CA does not provide requested information in a timely manner, then the application will take even longer, or be cancelled.
The overall steps of the CA certificate inclusion process are as follows.
# Carefully consider whether your CA needs to be [[CA/Included_Certificates|directly included in Mozilla's root store]] or if it would be better for your CA to be a [[CA/Intermediate_Certificates|subordinate CA A representative of an already-included CA]].#* If you control all the domains that use your root certificate, then you probably do not meet the criteria for inclusion in Mozilla's root store. [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy] states: "We will determine which CA certificates are included in software products distributed by Mozilla, based on the benefits and risks of such inclusion to typical users of those products." With ALL affected domains under your control, your root certificate would not seem to create a benefit for typical Mozilla users, only for users of your services. Perhaps a better alternative is to be a [[CA/Intermediate_Certificates|subordinate CA]] of a CA who is already [[CA/Included_Certificates|included in Mozilla's root store]].Application_Instructions#* According to [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's CA Certificate Policy]: "We require that all CAs whose certificates are distributed with our software product ... provide some service relevant to typical users of our software productsCreate_Root_Inclusion." It is the CA's responsibility to explain why their root needs to be included in NSS and explain how the inclusion will benefit typical Mozilla users.# A representative of the CA [[CA:How_to_apply#Creation_and_submission_of_the_root_CA_certificate_inclusion_request 2FUpdate_Request| submits a request for root inclusion.]] #* If you would like to see a particular root certificate included in Mozilla products, then please contact the CA who operates that root certificate.# A representative of the CA and [[CA:Information_checklist | provides information about the CA and operation of the root certificate(s).]]#* [[CA:Recommended_Practices#CP.2FCPS_Documents_will_be_Reviewed.21|CP/CPS Documents will be reviewed]], and must contain sufficient information for Mozilla and the CA Community to evaluate the CA's processes in regards to Mozilla's policies and the CA/Browser Forum's Baseline Requirements.#** English translations must be provided for the relevant CP/CPS documents, and must match the current version of the CP/CPS documents.# A representative of Mozilla [[CA:How_to_apply/Application_Verification#Information_Verification | verifies the information provided by the CA.]].
# A representative of Mozilla [[CA/Dashboard#Ready_for_Public_Discussion|adds the request to the queue for public discussion.]]
# Anyone interested in the CA's application [[CA:How_to_apply#Public_discussion | participates in discussions of CA requests further up in the queue.]]# When the application reaches the head of the queue, a representative of Mozilla starts the [[CAhttps:How_to_apply//groups.google.com/forum/#Public_discussion|!forum/mozilla.dev.security.policy public discussion]] for that particular CA.
#* We prefer that at least two independent parties review and comment upon each application.
# A representative of the CA [[CA:How_to_apply#Public_discussion | responds to questions and concerns posted during the public discussion of the CA's request.]]# A representative of Mozilla [[CA:How_to_apply#Public_discussion | summarizes the discussion and resulting decisions or action items.]]
#* A discussion may be put on hold, pending a CA action item, such that the discussion may continue as soon as the CA has provided the requested information.
# A representative of the CA [[CA:How_to_apply#Public_discussion | completes action items resulting from the public discussion,]] which may include updating processes, documentation, and audits.# A representative of Mozilla [[CA:How_to_apply#Public_discussion | confirms the completion of the action items and starts a second round of public discussion if needed.]]# A representative of Mozilla [[CA:How_to_apply#Public_discussion | concludes the public discussion of the CA's request.]]
#* If there are outstanding issues that need to be addressed (e.g., a need for further information, or concerns about CA practices) then the request may be closed, moved back to the Information Verification phase, or put on hold pending future discussion after the CA has addressed the concerns.
# A representative of Mozilla [[CA:Tentative_approval_template | summarizes the request and states the intent to approve the request for inclusion.]]
#* This is the last call for objection. After one week, if no further questions or concerns are raised, then the representative of Mozilla may approve the request, by stating so in the bug.
# A representative of Mozilla [[CA:How_to_apply#Inclusion | creates a bug requesting the actual changes in NSS (and PSM for EV treatment).]]
#* A representative of the CA confirms that all the data in the NSS bug is correct.
#* A representative of Mozilla creates a patch with the new CA certificates and trust bit settings, and provides a special test version of Firefox. Changes to NSS regarding CA certificate applications are usually grouped and done as a batch when there is either a large set of changes or about every 3 months.
#* A representative of Mozilla adds (commits) the patch to NSS, then closes the NSS bug as RESOLVED FIXED.
# Mozilla products move to using a version of NSS which contains the certificate changes. This process is mostly under the control of the release drivers for those products. See [https://wiki.mozilla.org/RapidRelease/Calendar Mozilla's Release Calendar.]
# After inclusion of the CA's root certificate, a representative of Mozilla issues a [[CAhttp:CommonCADatabase|//ccadb.org/ Common CA Database (CCADB)]] license to the [[CA:Information_checklist#CA_Primary_Point_of_Contact_.28POC.29|Primary Point of Contact]] for the CA.# The CA [[CA:SalesforceCommunity#Data_that_CAs_can_Add.2FModify|enters data into the CCADB]] for:
#* All of the certificates that are capable of being used to issue new certificates, and which directly or transitively chain to their root certificate(s) included in Mozilla’s Root Store that are not technically constrained as described in section 5.3 of [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].
#* [[CA:SalesforceCommunity#Add_Revoked_Intermediate_Certificate_Data_to_the_CCADB|Revoked intermediate certificates]] that chain to their certificate(s) included in Mozilla's Root Store.
Our most pressing need is help with reviewing and contributing to the public discussions of CA applications. If a CA you care about is in the [[CA/Dashboard#Ready_for_Public_Discussion|queue for public discussion]], the best way to move it towards inclusion is to quickly and diligently review and contribute to discussions of the applications of CAs ahead of it.
* [[CA/Dashboard#Ready_for_Public_Discussion|Queue for public discussion]]
* [[CA:How_to_apply#Public_discussion | Reviewing applications and contributing to discussions]]
