Confirm
344
edits
Changes
→Process Overview: Revised root inclusion process to move public discussion up in the sequence.
The overall steps of the CA certificate inclusion and update process are as follows. There are [[CA/Bug_Triage#Root_Inclusion.2FChange_requests_and_EV_Treatment_Enablement_Requests|Bugzilla Bug Whiteboard tags]] corresponding to many of these steps.
# A representative of the CA
#* [[CA/Application_Instructions#Create_Root_Inclusion.2FUpdate_Request|submits a request for root inclusion]] in both Bugzilla and in the CCADB (a representative of Mozilla issues a [httphttps://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), and
#* [[CA/Information_Checklist | provides information about the CA and operation of the root certificate(s).]]
#* All information provided by the CA MUST be publicly available.
#* If the CA contracts to another organization to help with the root inclusion request, the representative of the CA must clarify that relationship in their request, and must provide clear information about who the ongoing [[CA/Information_Checklist#CA_Primary_Point_of_Contact_.28POC.29|points-of-contact]] will be for the CA.
# A representative of Mozilla or the CCADB [[CA/Application_Verification#Information_Verification|verifies the information provided by the CA]].See [https://www.ccadb.org/cas/public-group# A root-inclusion-public-discussion Prerequisites to public discussion on the CCADB list] # [[CA/Application_Verification#Public_discussion|Public discussion]] for a six-week period begins in the [https://groups.google.com/a/mozilla.org/g/dev-security-policy CCADB discussion list]. If no concerns are raised during that time period, then the discussion may close and the request may proceed to the approval phase.# During the public-discussion phase, a representative of Mozilla , another root store, or of the CA Community (as agreed by a Mozilla representative) performs a [[CA/Application_Verification#Detailed_Review|detailed review of the CA’s CP/CPS and audit documents]]. During this phase, the CA may be required to update their CP/CPS and audit documents to become fully aligned with [https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ Mozilla's Root Store Policy].
#* [[CA/CPS_Review|Previous detailed reviews of CA CP/CPS and audit documents]]
# A representative of the CA responds to questions and concerns posted during the public discussion of the CA's request.
# A representative of Mozilla or the CCADB summarizes the discussion and resulting decisions or action items.
#* A discussion may be extended beyond the initial comment period if concerns or questions are raised that require further attention.
#* 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 Mozilla 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 states the an 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 a representative of Mozilla may approve the request, by stating so in the bug.
# A representative of Mozilla [[CA/Application_Verification#NSS_and_PSM_Bug_Creation|creates a bug requesting the actual changes]] in NSS (and PSM for EV treatment).
# 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 the CA [[CA/Application_Instructions#Test|tests the code changes]] using the test version of Firefox and confirms (by adding a comment in the NSS bug) that the correct certificate(s) is /are included and that the trust bits are correctly set.
# A representative of Mozilla requests that another Mozilla representative review the patch.
# 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.]
# The CA 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/#532-publicly-disclosed-and-audited Mozilla's Root Store Policy]; and
#* Revoked intermediate certificates that chain to their certificate(s) included in Mozilla's Root Store.
