Final minutes for the validation-sc meeting at the F2F on 2025-06-12
Corey Bonnell
These are the final minutes for the meeting indicated in the subject as captured by Martijn Katerbarg and approved at the validation-sc teleconference on August 7th.
# Validation Subcommittee – Meeting Minutes
Date: 12 June 2025
Location: CA/Browser Forum Face-to-Face – Toronto
- Antitrust Statement: Read by Corey
- Approval of Previous Minutes:
- Minutes from 29 May 2025 were approved.
## Agenda
1. CA-assisted Domain Validation: SC-88 (Slaughter)
2. Validation Summit Planning, 2025 Edition
3. Top-Level Domain Validation (time permitting)
4. Interaction with Wildcards (time permitting)
5. Revisiting High Risk Requirements (time permitting)
## Discussion Summaries
### 1. CA-Assisted Domain Validation → SC-88
Presenter: Michael Slaughter (Amazon Trust Services)
- Context & History
- Originally SC-82: CA-assisted domain validation (modification of Method 7 – DNS Change).
- Voting failed in November; discussion continued beyond ballot.
- Last update provided at Tokyo F2F; feedback resulted in major revisions.
- Key Decisions Since Tokyo
- Move away from Method 7 modification → introduce new DCV method.
- Use DNS TXT record with persistent value (rather than CNAME).
- Require MPIC .
- Separate DNSSEC language (covered under SC-85).
- Consensus Items
- Method renamed: “DNS TXT Record with Persistent Value”.
- Reuse Period:
- Min: 8 hours or TTL, whichever greater.
- Max: per BR 4.2.1 (currently 398 days, trending down to 10 days by 2029 via SC-81).
- Fixed label: `_validation-persist`.
- Format: RDATA includes CA name + account URI (defined by CA).
- Security Analysis:
- Contribution from Henry for structured security review framework.
- TTL-based reuse approach analyzed for risks.
- Next Steps
- Complete ballot preamble.
- Publish draft on Server Cert WG GitHub, open for comments.
- Goal: enter discussion period soon.
Discussion Points:
- Terminology precision (use “Authorization Domain Name” instead of generic “subdomain”).
- Clarify scope of account URI (CA-defined, may align with ACME account ID).
- Account URI not required to be a working URL; must be validated by CA as tied to applicant.
- Future consideration: ACME challenge type for this method.
### 2. Validation Summit Planning (2025 Edition)
Presenter: Corey Bonnell
- Previous summit: 2018
- Comprehensive review of validation methods, invited experts, led to multiple ballots.
- Why another summit now?
- Major changes since 2018:
- BGP hijacks, network-based attack mitigations (e.g., MPIC).
- Automation/ACME adoption.
- SC-81 reducing validation reuse to 10 days by 2029.
- Question: Are some BR-approved methods too manual for modern timelines?
Proposed Objectives:
- Holistic review: security, agility, automation readiness.
- Consider removal or deprecation of outdated methods.
- Focus on real-world operational impact, not just technical feasibility.
Ideas Raised:
- Survey CAs:
- Frequency of DCV method usage.
- Value assessments.
- Solicit topics for summit agenda.
- Include implementation experiences
- Possibly wait for data from upcoming ballot requiring disclosure of validation method in certificates.
Key Points:
- Avoid 2018-style “method-by-method” approach.
- Frame discussion around goals:
- Secure.
- Automatable.
- Scalable.
- Combine survey with topic-gathering.
- Timeline: decision whether to wait for cert-embedded validation method data.
Next Steps:
- Develop and circulate survey
- Gather topics via survey responses.
### 3. Revisiting High Risk Requirements
- Current State (BR 4.2.1)
- “CAs MUST identify and apply additional verification activity for High Risk Certificate Requests.”
- Definition: vague, historically tied to phishing domain concerns.
Discussion:
- Consensus: Requirement is outdated and provides little security value.
- No measurable or standardized approach; creates audit ambiguity.
- Does not prevent phishing; phishing sites have extremely short lifetimes.
- Duplicate efforts with existing legal/sanctions requirements.
- Adds manual complexity, undermines automation.
- Impact on EV/OV:
- EVGL references BR high-risk language → needs cleanup if removed.
- Alternative suggestions:
- Change “MUST” to “SHOULD”.
- Completely remove language for DV; possibly also for OV/EV.
- Eliminate associated revocation requirement for “fraudulently misleading” wildcards.
General Agreement:
- Strike from BRs entirely.
- Remove from EVGL (or update references).
- CAs may maintain internal risk processes voluntarily.
Next Steps:
- Trev’s team to draft ballot:
- Remove high-risk requirement from BRs and EVGL.
- Remove related revocation requirement.
--
You received this message because you are subscribed to the Google Groups "Management (CA/B Forum)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to management+...@groups.cabforum.org.
To view this discussion visit https://groups.google.com/a/groups.cabforum.org/d/msgid/management/DS0PR14MB6216189EA12E2A56547AA9AF925FA%40DS0PR14MB6216.namprd14.prod.outlook.com.