Prioritization of Root CA Inclusion Requests
All, I'd like to have you review the prioritization proposal below, which will help us as we process CA inclusion requests. ( https://wiki.mozilla.org/CA/Application_Process) Thanks, Ben --- Prioritization of CA Root Inclusion Requests will be based on the factors described below and use the P1-P5 Priority categories available in the Bugzilla system with our own priority categorization for the CA root inclusion program. - *P1 = High* (Applicant has good compliance history and is replacing an already-included root) - *P2 = Medium High* (Applicant is well-prepared and responsive, with a good history of policy compliance) - *P3 = Medium *(Applicant’s request and responsiveness are “average”, but demonstrates compliance with policies) - *P4 = Medium Low* (Applicant’s responsiveness and compliance history are “average”) - *P5 = Low *(Applicant has much work to do, is slow to respond to requests, or has not demonstrated full compliance with policies) Factors assessed in setting the above-referenced priorities, in order of importance, are: 1 - Alignment with Mozilla Manifesto - https://www.mozilla.org/en-US/about/manifesto/ 2 - Compliance (Based on the compliance history of existing CA operators, and their responsiveness to issues) https://wiki.mozilla.org/CA/Incident_Dashboard 3 - Replacing Existing (Existing CA operators that are replacing an already-included root certificate) https://wiki.mozilla.org/CA/Certificate_Change_Process 4 - Responsiveness/Complete and Timely (Applicant provides clear, complete, concise and timely responses to questions, comments, or concerns about their root inclusion request) 5 - Single-Purpose, Separate Roots (Hierarchies that are separated by root for a particular purpose) https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#CA_Hierarchy 6 - CA Hierarchy Control (CA hierarchies comprised solely of CAs fully controlled by the applicant) https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#53-intermediate-certificates 7 - Completeness (Applicant completes all information in CCADB) https://wiki.mozilla.org/CA/Information_Checklist#Create_a_Root_Inclusion_Case 8 - CPS Quality (Initially provided CP/CPS documents fully meet Mozilla’s Root Store Policy and the CAB Forum Baseline Requirements) https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Publicly_Available_CP_and_CPS 9 - Updating Trust Bits or EV-Enablement of Already-Included Root Certificate (Existing CAs that are only requesting EV enablement or adding a trust bit to an already-included root certificate) https://wiki.mozilla.org/CA/Certificate_Change_Process#Enable_EV 10 - Ready (Detailed CP/CPS Review is complete and CA is “Ready for Discussion”) https://wiki.mozilla.org/CA/Application_Verification#Detailed_Review ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New intermediate certs and Audit Statements
On 3/24/21 5:32 AM, Rob Stradling wrote: On 9th July 2019, Kathleen wrote: I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. Hi Kathleen. CCADB now automatically shows the following message (when relevant) in red text at the top of each intermediate certificate page: "This certificate was created after the audit period of the current audit statement, so please make sure to include it in the CA's next periodic audit statement." Do you still expect CAs to "use the Public Comment field to indicate that the new certificate will be included in the next audit statements"? Or may we stop doing that now? Thanks. Rob, Thanks for bringing this up. I agree that it is not necessary to use the Public Comment field to indicate that the new certificate will be included in the next audit statements. CAs may stop doing that. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New intermediate certs and Audit Statements
On 9th July 2019, Kathleen wrote: > I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. Hi Kathleen. CCADB now automatically shows the following message (when relevant) in red text at the top of each intermediate certificate page: "This certificate was created after the audit period of the current audit statement, so please make sure to include it in the CA's next periodic audit statement." Do you still expect CAs to "use the Public Comment field to indicate that the new certificate will be included in the next audit statements"? Or may we stop doing that now? Thanks. From: dev-security-policy on behalf of Kathleen Wilson via dev-security-policy Sent: 09 July 2019 22:50 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: New intermediate certs and Audit Statements All, There is some confusion about disclosure of new intermediate certs that are issued to subordinate CAs with currently valid audit statements. Section 5.3.2 of Mozilla's Root Store Policy says: "If the CA has a currently valid audit report at the time of creation of the certificate, then the new certificate MUST appear on the CA's next periodic audit reports." I think it is reasonable to assume that the same policy applies to subordinate CAs, such that if the subordinate CA has a currently valid audit report at the time of creation of a new intermediate certificate, then the new certificate MUST appear on the subordinate CA's next periodic audit reports. The confusion is about how to disclose such a new intermediate certificate in the CCADB. I propose that to handle this situation, the CA may enter the subordinate CA's current audit statements and use the Public Comment field to indicate that the new certificate will be included in the next audit statements. (Also, a quick comparison of the cert's Valid-From date and the audit period dates will indicate this situation.) Please let me know if you foresee any problems with this approach. Thanks, Kathleen ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
