Draft Minutes Validation Subcommittee - December 12, 2024
Clint Wilson
## Minutes of Validation Subcommittee
December 12, 2024
## Attendees
Aaron Gable (Let's Encrypt), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Rasmussen (OATI), Dimitris Zacharopoulos (HARICA), Dustin Hollenback (Microsoft), Iñigo Barreira (Sectigo), Janet Hines (VikingCloud), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Li-Chun Chen (Chunghwa Telecom), Luis Cervantes (SSL.com), Mads Henriksveen (Buypass AS), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Nargis Mannan (VikingCloud), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Roman Fischer (SwissSign), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)
## 1. Roll Call
## 2. Read Antitrust Statement
The statement was read concerning the antitrust policy, code of conduct, and intellectual property rights agreement.
## 3. Review Agenda
Wayne Thayer is leading the meeting.
## 4. Approval of minutes from last teleconference
The minutes for the teleconference of November 14, 2024 were approved.
## 5. Discussion
### SC-082
- While the ballot did not pass, a lot of feedback and input has been gathered in the process.
- Slaughter intends to create a new ballot based on those discussions. Applicants appreciate lower friction in performing DCV, which needs to be balanced against the necessity of meeting the security expectations of relying parties.
- There’s a belief that a “static DCV” method can be implemented with a strong security model.
- There is likely a need to clarify the semantic differences between a 3rd party offering a DNS delegation service and receiving the Random Value from the Applicant and a DNS delegation service that gets the Random Value directly from the CA.
- The proposed modifications to Method 7 in SC-082 aimed to clarify the issue and prevent mistakes, rather than creating a whole new validation method.
- Creating a new method that uses DNS CNAME records to permanently delegate domain validation to the CA would require significant time for crafting language, security analysis, and implementation.
- There is a suggestion to copy Method 7 into a new Method (e.g. Method 23) and edit it as a separate domain validation method, which could be more incremental in nature.
- Slaughter and others supporting this effort will also explore using CAA records to automate validation, though that may take time.
- Slaughter plans to lead further discussion, in the near term by gathering additional feedback on possible approaches to addressing this problem space — including the idea of creating a new DCV method — and will present some of those options in order to seek input from a broader audience at a future Validation Subcommittee meeting.
## 6. Any other business
## 7. Next call
Next call: Thursday, January 9, 2025
## Adjourned
Doug Beattie
These are the Draft Minutes of the Teleconference described in the subject of this message, prepared by Doug Beattie (GlobalSign).
Please review the minutes and propose edits if necessary. These minutes will be considered for approval at the next meeting.
==Note Well==
Corey read the Note Well.
==Attendees==
Aaron Poulsen (Amazon), Adriano Santoni (Actalis S.p.A.), Andrea Holland (VikingCloud), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Doug Beattie (GlobalSign), Dustin Hollenback (Microsoft), Enrico Entschew (D-TRUST), Georgy Sebastian (Amazon), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), Iñigo Barreira (Sectigo), Jaime Hablutzel (OISTE Foundation), Janet Hines (VikingCloud), Johnny Reading (GoDaddy), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Kiran Tummala (Microsoft), Luis Cervantes (SSL.com), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Miguel Sanchez (Google), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Paul van Brouwershaven (Entrust), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), Puja Sehgal (Microsoft), Rebecca Kelly (SSL.com), Rollin Yu (TrustAsia), Ryan Dickson (Google), Scott Rea (eMudhra), Stephen Davidson (DigiCert), Thomas Zermeno (SSL.com), Tobias Josefowitz (Opera Software AS), Trevoli Ponds-White (Amazon), Wayne Thayer (Fastly), Wendy Brown (US Federal PKI Management Authority)
==Agenda==
No changes to the agenda are requested.
===Approval of Minutes===
The November 14th minutes are previously approved and were just posted to the list
The December 12th minutes have not been sent out yet (Clint)
===Continue discussion of SC-82 - Clarify CA Assisted DNS Validation under 3.2.2.4.7 ===
Ballot SC-82: Clarify CA Assisted DNS Validation under 3.2.2.4.7 | CA/Browser Forum
While the ballot failed, there is continued interest in clarifying how CAs can support this domain validation method.
Slaughter said he’s working on some updates and follow up from the more detailed discussion that took place at the last VWG meeting. There will be updates and a new pull request coming soon and we will discuss this at the next VWG meeting in more detail. Please engage via github and look out for upcoming emails.
To recap the two central questions: 1)What properties and characteristics should this method have and 2) what do we do about the current method 7. We’ll get into the details on the list and the next upcoming VWG meeting
===Discussion of Wayne’s ballot: SC-XX: Process RFC 8657 CAA Parameters===
https://github.com/cabforum/servercert/pull/567
Wayne led the discussion. This ballot proposes the ability to restrict issuance not only by the CA, but by two things, domain validation method and the account that is the customer’s account with the CA. The most recent discussion we had was around a RFC 8657 that implements this well for ACME and also includes language to support non ACME requests. Wayne then went through the current draft ballot as show in the link above.
Rob’s 2 comments were accepted, one was wording and the other was a recommendation to begin the string with “CA-“ when specifying the Domain validation method. see the pull request for details.
Roman recently made a comment that we should consider making this a SHOULD vs. a MUST, or pushing the date out from 15 September 2025 into 2026
RFC 8657 talks about how to define labels for ACME and also provides guidance for how to define non-ACME labels and CPS requirements when doing so.
Rob proposed a change to permit the CA to define what validation methods labels they recognize will actually solve the problem of a conflict between ACME and non-ACME methods. The RFC defines ACME methods which are actually hard coded into the RFC or are hard coded into an IETF list of, of acceptable labels. So an ACME label would be like DNS-01 but that would actually cause confusion between whether a customer should use the DNS based validation method number “7” versus the Acme specific DNS validation method that isn't specified in the BRs. Allowing the CA to define this, actually helps with that problem at the possible expense of confusion for users that are using multiple CAs where they would need to implement different records for each CA or different validation method label syntax for each CA.
Wayne went on to say that RFC 8657 has a statement that a CA supporting the account URL parameter of the validation methods parameter must perform CA validation using a trusted DNSSEC validating resolver. If we require compliance with the RFC, we're also requiring CAs to use DNSEC to validate these methods. And it's a little unclear whether we would be essentially saying that you have to start doing DNS SEC validation for or requiring DNSSEC for validation for all CAA checks. So that is a problem that needs to be solved.
Clint provided this link which is a branch that has additional information about DNSSEC (If the zone has enabled DNSSEC you must use it, and it clarifies a way to verify if the zone has DNSSEC). It goes a bit further into describing about whether or not it has DNSSEC enabled and then it makes sure that you validate DNSSEC when it’s present
It might make sense to combine the 2 ballots
Corey said that we should try to come up with URI scheme that both ACME and non-ACME customers can use. Right now, only ACME is defined in RFC 6857
Wayne said that Customers will have to look up account identifier format for non-ACME anyway, so should not an issue for them to look at CPS for format of domain validation method.
Corey suggested a standard structure like using a “non-ACME” prefix
In the end of the discussion, Wayne agrees we should try to extend to describe a scheme how to encode account ID for non-ACME use.
Trev pointed out some challenges customers have when using different CAs that documentation by itself doesn’t solve this problem.
Corey's advice is that we extend this this proposal slightly to describe some scheme of how to encode the account ID for a CA here.
Stephen said that SMIME has methods defined beyond TLS so we should come up with a scheme that supports S/MIME
Wayne said that the initial approach was a format like CA-BR-number which can support also SMIME. By allowing CAs to define the semantics themselves we avoid that problem.
However, Slaughter said he has less of concerns if a CA wants to allow DNS-01 and/or TLSBR method 7 as long as the CA TLSBR method seven is consistent across the CAs. He does not have a very strong opinion about what that consistent label is.
Martijn commented that if CAs can define it themselves, then certainly as a group we could define them so it’s unified across all CAs.
Corey agreed with Martijn that we should standardize how BR methods are defined as well.
Wayne: said that we can do that if we're willing to punt on the concern of conflicting methods and say that the CA gets to decide what to do when they're using Acme DNS-01 one and the validation methods label contains CA-TLSBR-7. The answer to that would be that both of those are probably acceptable, and he thinks that then creates, the potential for confusion on the subscribers that are configuring the CA methods.
Wayne said that it’s assumed that only sophisticated users will want to use these only using this, so they can figure it out. But happy to revert Rob’s comment back to use method number as a standard. There can be multiple for the same method as there are 2 different ways to reference the same method.
Corey: some customers may have account URI for ACME and there is a different one for non-ACME which is better than having unique ones for every CA.
- Conclusion from Wayne
- Work with Clint on DNSSEC alignment
- Define better semantics for account URI
- Define more about how we assign the BR methods
- Update the pull request
===Discussion of Wayne’s DNS-ACCOUNT-01 ballot===
https://github.com/cabforum/servercert/pull/566
Recap: There is an issue with ACME DNS-01 validation method when you want to delegate via CNAME. That ACME method specifies that the CNAME record must be in the “_acme-challenge” subdomain and since there can be only one CNAME per zone, this precludes multiple CA from being used. Wayne’s draft ballot proposes to use this draft RFC to support additional CNAMEs for a specified domain: https://datatracker.ietf.org/doc/draft-ietf-acme-dns-account-label/. It encodes the ACME Account ID into an additional label that is prepended to the to the URL that's used for the DNS challenge. And because the account ID is unique across CAs you can have as many CNAMEs as you have accounts.
The BRs only allow one label to be prepended to CNAME records, but the RDATA value is not specified so you may have as many CNAME records as needed by just creating additional different subdomains that begin with an underscore. This proposed new domain validation method is therefor only needed to extend the ACME dns-01 method.
Wayne is looking for endorsers on VWG list and then will move to server cert WG and start a discussion period
===Discussion of SC-081 - Introduce Schedule of Reducing Validity and Data Reuse Periods ===
https://github.com/cabforum/servercert/pull/553/files
Not much movement recently over the holidays. There are 3 endorsers
Clint will move forward once discussion has settled down and all comments addressed and then move into formal discussion period.
Wendy would like to have extended discussion period. She’s still trying to gather feedback from the government users. Clint said it would not be just a 1-week review period.
Clint agreed that there would be an extended discussion period.
Meeting was adjourned