Exploring an alternative approach to the Validation Summit

[Ryan Dickson]

Hi all,

At yesterday’s Validation Subcommittee Meeting, we (Chrome) shared our views on the utility of a CA Owner survey to collect information on the frequency of validation methods’ use across the community. Our understanding was that the survey responses were intended to guide future discussions as part of an upcoming “Validation Summit” - where the community would evaluate existing domain and IP address control validation methods permitted by the TLS BRs against different sets of criteria.

Ultimately, we arrived at the conclusion that a survey would not be the most effective and efficient use of time, and would instead delay beneficial outcomes that might result from focusing the community’s attention. Our justification for this view includes:

• While it might be interesting to know the frequency of a method’s use, its popularity alone is not a good indicator as to whether it should continue to be supported by the TLS BRs.
• Understanding the number of certificates relying on a specific method does not adequately convey the complexity or effort required by subscribers to transition to a different method.
• While it’s true that usage could help guide understanding the impact of a potential sunset, and could help in identifying timelines that balance the tradeoffs of doing so, that’s better as a trailing activity, not a leading activity.
• Most importantly, if a method is fundamentally weak, insecure, or generally not well aligned with the expectations included in the TLS BRs, it should be planned for removal. Systemically eliminating weak links reduces attack surface and improves the overall security of the ecosystem.

We also encouraged prioritizing time for Henry Birge-Lee to present his evaluation of DCV methods following Open MPIC’s implementation. Several meetings ago, Henry described what he felt were security issues with some of the existing methods. It sounds like Henry will have an opportunity to present at the next Validation Subcommittee meeting and we look forward to learning more.

Also concerning the future approach of the subcommittee’s efforts, we referenced our opinions shared during the SC-080 and SC-081 discussion periods, and those represented in our February policy update. At a high-level, those views focused on reducing the use of validation methods that lack the same level of security guarantees as other methods - and those that suffer with what we perceive to be agility and scaling issues.

This community’s endorsement of subscribers relying on validation methods, evidenced by their continued inclusion in the TLS BRs, that cannot reliably satisfy the expectations therein, increases risk and should be considered harmful to the ecosystem. Thinking a subscriber who is relying on postal mail DCV (permitted by 3.2.2.5.2) could effectively manage a 24-hour key compromise revocation is unrealistic. Extending that scenario to a subscriber with hundreds or thousands of certificates is something far worse.

We have a more detailed initial proposal here that recommends a phased sunset of validation methods as follows:

Effective March 15, 2027:

• Method 3.2.2.4.16 ("Phone Contact with DNS TXT Record Phone Contact")
• Method 3.2.2.4.17 ("Phone Contact with DNS CAA Phone Contact")
• Method 3.2.2.5.2 ("Email, Fax, SMS, or Postal Mail to IP Address Contact")
• Method 3.2.2.5.5 ("Phone Contact with IP Address Contact")

Effective March 15, 2028:

• Method 3.2.2.4.4 ("Constructed Email to Domain Contact")
• Method 3.2.2.4.13 ("Email to DNS CAA Contact")
• Method 3.2.2.4.14 ("Email to DNS TXT Contact")

Feedback is welcome, as would anyone’s interest in endorsement to help facilitate broader discussion.

We recognize that changes to permitted DCV methods are significant and should be carefully considered. It’s also true that they can offer substantial long-term benefits that outweigh the associated risks. Strengthening the ecosystem’s security, resilience, and agility now will better prepare it for foreseeable future challenges, such as reduced certificate lifetimes and the eventual shift to quantum resistant cryptography. This will also aid in managing near-term unknown or unpredictable certificate lifecycle management events.

To help set expectations, it is our preference to more strongly pursue this proposal upon the completion of SC-088, and consider the outcomes introduced by SC-088 as a useful tool for easing the transition for subscribers currently relying on the methods proposed for sunset.

Thanks,
Ryan (on behalf of the CRP)