MRSP 3.0: Issue #283: Automation of certificate issuance and renewal

[Ben Wilson]

All,

This email starts a discussion related to GitHub Issue #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, 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

[Dustin Hollenback]

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

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZSvQWjAjBseFN1A1TNGk5LD6_07xOm9LuL8T_8sLupmg%40mail.gmail.com.

[Ben Wilson]

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

[Dustin Hollenback]

Awesome. Thanks, Ben!

---

From: Ben Wilson <bwi...@mozilla.com>
Sent: Wednesday, January 8, 2025 8:58:07 PM
To: Dustin Hollenback <Dustin.H...@microsoft.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: [EXTERNAL] MRSP 3.0: Issue #283: Automation of certificate issuance and renewal

 

[Adriano Santoni]

Ben,

to better understand the rationale of the proposed requirement: 

how does publishing a website whose TLS certificate is renewed every 30 days demonstrate that the CA actually performs such renewal in an automatic fashion?

TIA

Adriano

Il 09/01/2025 04:58, 'Ben Wilson' via dev-secur...@mozilla.org ha scritto:

NOTICE: Pay attention - external email - Sender is dev-security-policy+bncBDIP...@mozilla.org

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZsNmb03GfvaNWJdcD3sWFwms%2BsroAd7bhaR1nUruPyyQ%40mail.gmail.com .

[Rob Stradling]

> Currently, the CCADB has a field for each of type of certificate (IV, DV, OV, EV) to track the test websites

Hi Ben.  Are you referring to these 4 fields that are currently in the "Google Chrome Fields" section of each Root Certificate record?

Field: DV Automation Test Certificate Website

Description: If DV certificates are issued under this hierarchy, add the URL of the test website that includes a valid DV (2.23.140.1.2.1) certificate issued by ACME or other automated solution.

Field: OV Automation Test Certificate Website

Description: If OV certificates are issued under this hierarchy, add the URL of the test website that includes a valid OV (2.23.140.1.2.2) certificate issued by ACME or other automated solution.

Field: EV Automation Test Certificate Website

Description: 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.

Field: IV Automation Test Certificate Website

Description: If IV certificates are issued under this hierarchy, add the URL of the test website that includes a valid IV (2.23.140.1.2.3) certificate issued by ACME or other automated solution.

If Mozilla intends to make use of these fields, then may I suggest moving them out of the Chrome-specific section?

---

From: 'Ben Wilson' via dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Sent: 09 January 2025 03:58

To: Dustin Hollenback <Dustin.H...@microsoft.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>

Subject: Re: [EXTERNAL] MRSP 3.0: Issue #283: Automation of certificate issuance and renewal

 

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaZsNmb03GfvaNWJdcD3sWFwms%2BsroAd7bhaR1nUruPyyQ%40mail.gmail.com.

[Ben Wilson]

Hi Rob,

That's correct. I'll mention that to the CCADB Steering Committee.

Thanks,

Ben

[Ben Wilson]

Hi Adriano,

If needed, we can clarify the language to communicate better our expectation that renewal of the test certificate is performed by an automated process and not manually. Also, discovery of any of the following would be a critical red flag, jeopardizing continued trust in the CA operator:

• Deliberate Violations: Intentionally failing to adhere to Mozilla’s Root Store Policy or other applicable guidelines;
• Lying or Deception: Providing false information about automation or similar matters; or
• Concealment: Failing to fully disclose the extent of a problem, such as manual renewal of test certificates or misrepresenting automation capabilities.

Thanks,

Ben

To view this discussion visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/101e36dc-9b0c-4cd5-8536-b7c1c50feeac%40staff.aruba.it.