[cabf_validation] Validation methods used for Wildcards/ADNs
sleevi at google.com
Tue Feb 2 20:30:51 UTC 2021
On Tue, Feb 2, 2021 at 3:14 PM Corey Bonnell <Corey.Bonnell at digicert.com>
> Hi Ryan,
> This WG discussed the allowance for HTTP-based domain validation to be
> performed at the ADN in late 2018 as a potential item to address as part of
> SC25. Given that the group decided to not modify this allowance in SC25,
> I’m wondering what the motivation is for this change now, especially
> considering that you mentioned “we've become aware of some CAs having
> poorly evaluated the security risks in this space”. Is this referring to a
> new threat that has been identified, or something else?
There are several things you've gotten wrong in your message, to varying
degrees, and I think this might explain the disconnect.
First, while this was discussed in the context of our Herndon meeting in
early 2018 (specifically, March 2018), you may recall that Google has
raised this in the past before then (e.g. in the discussions of
StartCom/WoSign validation practices, which were reiterating concerns
Google raised to the management list even older than that regarding such
Second, following that summit in Herndon, VA, the validation WG began to
work to address multiple issues that were highlighted, by dividing that
work into chunks to ensure productive discussion and collaboration. For
example, this work continued through SC2, SC7, SC13, SC14, SC15, SC18,
SC19, SC25, and SC33. This work is a continuation of our ongoing progress
being made, both on the issues known before our summit and identified
Third, the choice to not include this within SC25 was not because this was
and is not an important change, but in recognition of the differing
challenges with respect to how methods are sunset, and wanting to continue
to make meaningful progress.
Although our Herndon meeting serves as a useful anchor point, it's worth
noting the discussion of validation security well existed before that
attempt to formalize and track all of the issues - e.g. ballots such as
Ballot 218 were themselves part of the overall discussion of validation
security that began well prior to Ballot 169/181/190.
So the motivation is the same as it has always been, for over half a
decade: to ensure users are secure. While the CA/B Forum has made good
progress in the past three years, and we've made important progress on
thorny issues the validation WG has identified (e.g. the ongoing work on
certificate profiles, ballots such as SC12, SC16, and SC30), we cannot let
progress detract from the need to address these issues.
Importantly, given that this is one of the longest-standing issues the
Forum has been aware of, and because we explicitly designed ballots in
order to help minimize risk (specifically, the proviso in Ballot 169 to
record the validation method used).
Hopefully, this provides a useful refresher for the past activity in the
Forum, how this has been subject to years of discussion, and the importance
in continuing to make progress in closing a very clear and obvious security
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Validation