Awesome. Thanks, Ben! ________________________________ From: Ben Wilson <[email protected]> Sent: Wednesday, January 8, 2025 8:58:07 PM To: Dustin Hollenback <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [EXTERNAL] MRSP 3.0: Issue #283: Automation of certificate issuance and renewal
Thanks, Dustin, that's correct. I'll edit the language and remove the reference to the automation endpoint URL. Currently, the CCADB has a field for each of type of certificate (IV, DV, OV, EV) to track the test websites, which we can enable for Mozilla's inclusion requests when this change is made to the MRSP. For example, there is a CCADB field identified as "EV Automation Test Certificate Website", the instructions for that field state, "If EV certificates are issued under this hierarchy, add the URL of the test website that includes a valid EV (2.23.140.1.1) certificate issued by ACME or other automated solution." That's the intent - to start collecting and monitoring these automated capabilities for new root inclusion requests. Thanks again for your review and clarification. Ben On Wed, Jan 8, 2025 at 2:51 PM Dustin Hollenback <[email protected]<mailto:[email protected]>> wrote: Hi Ben, I fully support the goal of encouraging automation, but I'm a bit confused on this statement: "CA operators MUST disclose the URL for each such automation endpoint in the CCADB ..." I may be misinterpreting this to mean that the URL for an automation API is required to be published. In that case, I am hoping that the API details would not be required to be published, but instead only focus on the test websites. I understand providing a URL for where test certificates will be published to prove that they are updated every 30 days, but not sure why there'd be a requirement for an "automation endpoint" URL to be published. In our case, while we use non-ACME automation for DCV and issuance/renewals, the endpoints are not publicly accessible and restricted only to our Subscribers. For this proposal, would it be enough to provide a URL to the test certificates that are renewed every 30 days or less? Existing draft language: CA operators MUST disclose the URL for each such automation endpoint in the CCADB and renew test certificates using such capability at least every 30 days to demonstrate compliance with these automation requirements. Proposed draft language: CA operators MUST renew test certificates using such capability at least every 30 days to demonstrate compliance with these automation requirements and disclose the URL for each test site in the CCADB. Thank you, Dustin From: 'Ben Wilson' via [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Sent: Wednesday, January 8, 2025 1:17 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[email protected]>> Subject: [EXTERNAL] MRSP 3.0: Issue #283: Automation of certificate issuance and renewal All, This email starts a discussion related to GitHub Issue #283<https://github.com/mozilla/pkipolicy/issues/283> and Section 7.1 of the Mozilla Root Store Policy (MRSP), which deals with new root inclusions. The purpose of this proposal is to encourage automation. Currently, the proposed amendment to section 7.1 of the MRSP, as drafted in GitHub<https://github.com/BenWilson-Mozilla/pkipolicy/commit/9f933ac3f1829418554da8aa24ea2a20174852df>, states, "Additionally, CA operators applying for inclusion of new TLS-issuing root certificates MUST demonstrate support for at least one automated method of certificate issuance for each type of TLS certificate (EV, OV, DV, IV) that the CA issues. This means (1) automated domain control validation, as defined in the TLS Baseline Requirements; and (2) automated certificate issuance and retrieval processes. Such automated methods MUST minimize hands-on human input during routine certificate issuance and renewal processes and comply with the TLS Baseline Requirements, and EV Guidelines, if applicable. Acceptable "hands-on" input includes initial software setup, configuration, updates, and identity verification where required. CA operators MUST disclose the URL for each such automation endpoint in the CCADB and renew test certificates using such capability at least every 30 days to demonstrate compliance with these automation requirements." This language needs some wordsmithing. Also, I have not yet added any language to address automated renewal. Suggested language is welcome. In the interest of brevity, additional guidance and/or specifics of implementation would be included in a wiki page, and it is a goal for these to be similar to those in the Chrome Root Program Policy, so that the impact on CA operators would be minimal. Thanks, Ben -- You received this message because you are subscribed to the Google Groups "[email protected]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZSvQWjAjBseFN1A1TNGk5LD6_07xOm9LuL8T_8sLupmg%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZSvQWjAjBseFN1A1TNGk5LD6_07xOm9LuL8T_8sLupmg%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/LV3PR00MB2320F79FC926455399ADBF78F9132%40LV3PR00MB2320.namprd00.prod.outlook.com.
