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]> 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] < > [email protected]> > *Sent:* Wednesday, January 8, 2025 1:17 PM > *To:* [email protected] <[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]" 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/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/CA%2B1gtaZsNmb03GfvaNWJdcD3sWFwms%2BsroAd7bhaR1nUruPyyQ%40mail.gmail.com.
