2025-03-06 Final Minutes of the Validation Sub-committee

[Corey Bonnell]

Here are the final minutes of the meeting indicated in this email’s subject, as taken by Ryan Dickson and approved at the 2025-03-27 validation-sc meeting.

 

Meeting Date: 2025-03-06

 

Attendees*: Aaron Gable (Let's Encrypt), Aaron Poulsen (Amazon), Adriano Santoni (Actalis S.p.A.), Aneta Wojtczak-Iwanicka (Microsoft), Ben Wilson (Mozilla), Bruce Morton (Entrust), Chris Clements (Google), Clint Wilson (Apple), Corey Bonnell (DigiCert), Corey Rasmussen (OATI), Cynethia Brown (US Federal PKI Management Authority), Dustin Hollenback (Microsoft), Georgy Sebastian (Amazon), Gregory Tomko (GlobalSign), Gurleen Grewal (Google), Henry Birge-Lee (Henry Birge-Lee (Private person)), Kateryna Aleksieieva (Asseco Data Systems SA (Certum)), Li-Chun Chen (Chunghwa Telecom), Luis Cervantes (SSL.com), Mahua Chaudhuri (Microsoft), Martijn Katerbarg (Sectigo), Michael Slaughter (Amazon), Michelle Coon (OATI), Nate Smith (GoDaddy), Nome Huang (TrustAsia), Pedro Fuentes (OISTE Foundation), Pekka Lahtiharju (Telia Company), 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), Yamian Quintero (Microsoft)

 

*obtained from the Membership Tool

 

Read Note-well: Corey read the note-well.

 

Review Agenda: No changes to the agenda.

 

Approval of Minutes: The minutes for the teleconference of 20 February 2025 were approved.

 

F2F#64 Agenda Planning (Corey):

• 1.5 hours allocated in the schedule for the Validation Subcommittee.
• At last week’s SCWG meeting, we agreed to discuss DNSSEC during the Validation Subcommittee F2F block.
• Wayne indicated the CAA parameters ballot could fill time in the Validation Subcommittee meeting block, if time is available.
• Ryan asked about prior F2F discussion related to validation transparency - or the inclusion of DCV methods in certificates. Is that something that should be continued?
• Clint indicated he still has a branch open on GitHub - with some lingering discussion related to how to most efficiently include method information in certificates. 
• Corey’s recollection of the past discussion was that it took place in the SCWG, perhaps it’s a better fit there. Clint was happy to see the discussion move to the SCWG, or whichever meeting might accommodate discussion timing, should there be interest. 
• Henry offered the opinion that it is a better fit for the SCWG, and emphasized the value of a concrete proposal prior to any follow-up discussion. Clint intends to review the last status of the draft, as he thought this existed.
• Slaughter volunteered for an SC-82 Redux progress update.
• Trev described possible issues with wildcard validation given deprecated validation methods.
• Corey recommended we plan this discussion for the meeting following the F2F.
• Trev volunteered to file an issue to GitHub.
• The discussion concluded with three F2F topics:
• CAA Parameters (15m) (note: later discussion determined this block was no longer necessary).
• Progress update on SC-82 Redux (15m).
• DNSSEC (45m - 1hr) - where Henry will present his ballot proposal.

 

SC-82 redux (Slaughter):

• Recap: Last time we discussed this within the Validation Subcommittee, we… 
• discussed five potential options for carrying forward with the ballot.
• settled on a high-level approach that (1) adds a new method - 3.2.2.4.22 “DNS Change with Static Value” and (2) updates 3.2.2.4.7 to reference that new method and discourages the usage of anything related to the static DCV method concept (initially SHOULD, eventually transitioning to a MUST).
• Slaughter has since created a draft based off of Aaron G’s proposed TXT record-based approach.
• Today’s goal -> broadly discuss approaches for performing “static” DCV. This discussion will guide a more refined presentation and draft ballot text.
• Today, 3.2.2.4.7 allows three methods for DCV using DNS changes (TXT Record, CAA Record, and CNAME Record)
• The group discussed which of those options could be the best fit for static DCV:
• Henry questioned whether these records should be placed in root (i.e., “base domain”), or in the underscore-prefixed subdomain. Root might be cleaner, but it’s not clear what changes should look like in this context. 
• Martijn said it depends on which record you are using. With CAA and TXT records, you can add them to the base domain (what Henry referred to as “root”). In the CNAME case, this isn’t possible, without impacting the availability of the domain. Henry agreed, the CNAME case needs to rely on the underscore-prefixed subdomain.
• Wayne shared that challenges related to the CNAME use case, where only one value is permitted, are being addressed by DNS-ACCOUNT-01. Because we’ve already taken steps to address that problem, Wayne thought we could remove CNAME from the set of options being discussed. 
• Corey shared some benefits re: CNAME approach (e.g., operational advantages because you don’t need to provide PKI teams DNS access to the actual domain being validated). 
• Aaron G indicated TXT record on an underscore-prefixed subdomain should be considered the best option. You can only have one CNAME, and that’s a challenge. The CAA RFC says two things: 

1. a CAA record on an underscore-prefixed subdomain is meaningless

2. CAA does not allow issuance, it restricts issuance. 

1. We should not make decisions on authorization to issue based upon CAA. 

2. Tree climbing semantics also adds headache, avoiding that should be considered beneficial (as accomplished with a TXT record on an underscore-prefixed subdomain).

• Henry indicated it may be unknown to subscribers that adding a CAA domain contact email record may override CAA values in a parent domain. Not addressing those semantic issues in this ballot would be preferable. 
• Corey described tree climbing for contact address CAA records is more flexible than the checking semantics required in 3.2.2.8. CAA tree climbing semantics do not apply to the contact address lookups in 3.2.2.4.7 and possibly 3.2.2.4.13.
• Aaron summarized this debate and the inherent complexity is further justification for not relying on CAA. Basing static DCV off of TXT records is the simplest approach. 
• Slaughter questioned whether we knew if anybody is using method 7 with CAA records? No one was familiar. 
• Slaughter summarizes the discussion:

1. CNAME not valuable, adds risk. 

2. CAA records are complicated. 

3. TXT seems to be the most straightforward approach. 

• Martijn expressed concern given TXT records already serve many purposes beyond just in support of issuance - and it’s possible that DNS services limit the number of records returned. Corey agreed, and mentioned a draft RFC focused on DNS best practices references use of subdomains. The group agreed that approach makes sense. 
• Henry emphasized that putting tokens in CNAME, which per the DNS standards are to be followed to another record set, is inelegant. We should not degrade the intended function of CNAME, or introduce scenarios where we’re caught between RFCs - adding complexity and potential issues.
• General consensus concludes on use of TXT records.
• Slaughter presented a list of other considerations for general feedback from the group. Discussion was unstructured, participants could comment on any topic, as it interested them. 

1. Wildcard and subdomain validation

1. Henry: Yes, this should be supported. Security is derived from the existing DNS change validation methods. Since we allow this with normal DNS change, we should inherit the same permissions. Identical show of control of authorization with identity security properties. 

2. Slaughter called for disagreement, none presented.

2. MPIC

1. Henry: We’d naturally do MPIC here, too.

2. Slaughter called for disagreement, none presented.

3. Validation reuse:

1. Corey: We discussed a reduced DCV reuse period in the original ballot. Was that included here?

2. Slaughter indicated that approach was not included in the final version of the ballot. 

3. Corey: Rationale for including here - if this is a static check with no per-certificate request made by the applicant, we can be more aggressive with requiring DCV checks. That also means a client can remove that record and it’ll be acknowledged much more quickly.

4. Clint: Recommended we consider how this intersects with TTL (and the maximum TTL that should be honored). 

4. Effective date?

1. No discussion.

5. What is an account?

1. Slaughter indicated the lack of clear definition was a concern during the initial SC-82 effort. Do we need to explicitly define what it means to have an account?

2. Clint described ACME as having the best concept of an account. Outside of that, there’s not a great conceptualization of what it means to have an account with a CA when performing DCV.

3. Martijn asked whether that is something that should be defined by CAs in their CPS.

6. DNSSEC

1. Aaron G: Assuming this is covered in Henry’s proposal, this ballot does not need to consider it. However, if that doesn’t happen, this new, modern method, should require a stronger stance on security by requiring DNSSEC validation when DNSSEC is in use, even if we can’t do it for all other methods. 

7. Other definition updates?

1. No discussion

 

o   We ran out of time, and agreed to carry forward with (1) the progress update at the F2F, and (2) continuing discussion on defining what an account is following the F2F. 

 

CAA parameters ballot:

• Shared link to the PR in chat
• Last time, we landed on the need for two changes

1.     Split DNSSEC to its own Ballot, which Henry is working on. DNSSEC removed from the title of this ballot. Exceptions to treat record lookup failures as permission to issue were retained (representing no change from the BRs today). 

o   Wayne made the assumption this ballot would pass before Henry’s DNS ballot. Henry’s ballot could then overlay on top of this, should it make sense to do so Henry mentioned he thought that could work cleanly. 

2.               3.2.2.8 references 4.2 of the BRs, and that’s where CAA information needs to be documented in the CA’s CPS. S/MIME BRs have this in 4.2.2.1. We said to move CAA in the TLS BRs in a consistent way.

·        We can either remove the existing 3.2.2.8 and renumber sections, or leave 3.2.2.8 in place and add a breadcrumb pointing to 4.2.2.1 (as currently proposed). 

·        Due to external reliance on the TLS BRs, including the S/MIME BRs and ETSI standards, the breadcrumb approach was determined best. 

• After discussion, Wayne concluded the ballot was ready to proceed.Wayne will message the list requesting review and endorsement. No need to discuss at the F2F, given this outcome, resulting in more time for DNSSEC discussion.

 

Next call: To be held at F2F#64. There will be no meeting in two weeks (2025-03-20).

Adjourn: The meeting adjourned.