Final minutes for 2024-11-14 Validation Subcommittee meeting

258 views

Skip to first unread message

Corey Bonnell

unread,

Jan 8, 2025, 8:54:50 AMJan 8

to valid...@groups.cabforum.org

These are the Final Minutes of the Teleconference described in the subject of this message, prepared by Martijn Katerbarg (Sectigo). These minutes were approved during the 2024-12-12 meeting of the validation sub-committee.

==Note Well==

Corey read the Note Well.

==Attendees==

Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Gurleen Grewal (Google), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Joseph Ramm (OATI), Kiran Tummala (Microsoft), Li-Chun Chen (Chunghwa Telecom), Luis Cervantes (SSL.com), Mads Henriksveen (Buypass AS), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Rollin Yu (TrustAsia), Ryan Dickson (Google), Stephen Davidson (DigiCert), Steven Deitte (GoDaddy), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)

==Agenda==

No changes to the agenda are requested.

===Approval of Minutes===

The September 19th minutes are approved.

The October 17th minutes are approved.

The October 31st minutes are approved.

===Continue discussion of SC-81 - Reduce certificate validity and validation reuse periods===

Clint sent out an explainer as to the reasoning for these changes last week. Specific feedback is requested on the validity period steps, table heading texts and validation data reuse periods.

Based on previous feedback, the table row for 45 days DCV reuse has been removed.

It is raised that having a defined term for Validation Reuse Period would be a good thing. Clint will take a first look at this.

Additionally it’s raised that the current defined Subject Identity Information term does not exclude IP Addresses from the subjectAltName extension and the Subject commonName field. Martijn will look at this for the cleanup ballot.

Clint clarified that there’s no intent to further reduce the data reuse period for subject identity information within the scope of this ballot, but to keep it at 366 days.

Dimitris requests if we can align this to 398 days. Clint agrees to update the draft text.

===Standard CAA parameters===

Related to https://github.com/cabforum/servercert/issues/353. Wayne mentions they see an increased demand for limiting issuances to certain CA accounts.

Ryan adds they’d be in favor of adding a requirement to follow RFC 8657. In the past the Chrome Root Program received feedback that at least one CA software vendor was not ready for this, but it is believed this has been resolved since. The preflight Chrome Root Policy V1.6 adds such a requirement for new Applicant PKI hierarchies.

Wayne: Should we incorporate this in the BRs, or should we let the Chrome Root Program Policy address this? Ryan expresses the believe that he expects most people would rather see this within the BRs.

Dimitris raises that earlier it was discussed that there are some risks as domain owners could lock themselves out of being able to get a certificate issued.

Wayne believe this is not a big problem, since it’s not related to pinning, but rather limited to the DNS TTL, which reduces the risk window.

Wayne raises we need to define some validationmethods parameters and map them to the BR allowed DCV methods, such that the DNS Change method would become ca-dv-7.

Martijn proposes adding “tbr”, to differentiate from the S/MIME BRs which also use DCV methods. Wayne give “ca-tbr-7” as new proposal.

Dimitris asks how this would be different from DNS01?

Wayne adds that the RFC already has labels defined for these. We may need to clearly define which ones to use when.

There is a discussion if DNS-01 should be split out into the ACME only version or not, without a clear preference from the group.

Wayne will start drafting a ballot proposal.

===STRIDE model for DCV method #7===

This agenda item was pushed to the next call.

===Any Other Business===

Wayne: An updated RFC draft titled ACME DNS Labeled with ACME Account ID Challenge was published recently. If someone wants to delegate two ACME CAs to get certs for the same domain name, which is fairly common especially among larger enterprises, you can’t, and this hinders automation. We will need to amend the BRs at some point to account for this. Once this draft is in a stable form, I intend to draft a new validation method for this in the next few weeks. If there are any concerns, please do reach out.