<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 2, 2021 at 3:14 PM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" style="overflow-wrap: break-word;"><div class="gmail-m_3469716298718408714WordSection1"><p class="MsoNormal">Hi Ryan,<u></u><u></u></p><p class="MsoNormal">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?</p></div></div></blockquote><div><br></div><div>Hi Corey,</div><div><br></div><div>There are several things you've gotten wrong in your message, to varying degrees, and I think this might explain the disconnect.</div><div><br></div><div>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 validation)</div><div><br></div><div>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 during.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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 gap.</div></div></div>