<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:"Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@Yu Gothic";
panose-1:2 11 4 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle20
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:877860644;
mso-list-type:hybrid;
mso-list-template-ids:-378228248 1194123818 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;
mso-fareast-font-family:"Yu Gothic";
mso-bidi-font-family:"Times New Roman";}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal>Hi Ryan,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> 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)<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I don’t recall any messages from Root Programs on prohibiting “ADN != FQDN” HTTP-based validation surrounding the StartCom/WoSign incidents [1], as none of the WoSign incidents arose from such allowance. Those incidents arose from failing to prohibit a ADN subdomain from validating a parent FQDN, or allowing validation against HTTP servers running on non-privileged ports, etc. Given this, it would be useful if you could clarify your previous statement that “we've become aware of some CAs having poorly evaluated the security risks in this space” so that everyone has a full understanding of the motivation underlying that statement and how we can address the security concern.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Thanks,<o:p></o:p></p><p class=MsoNormal>Corey<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[1] <a href="https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29">https://wiki.mozilla.org/CA:WoSign_Issues#Issue_N:_Additional_Domain_Errors_.28June_2015.29</a><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Tuesday, February 2, 2021 3:31 PM<br><b>To:</b> Corey Bonnell <Corey.Bonnell@digicert.com><br><b>Cc:</b> CABforum3 <validation@cabforum.org><br><b>Subject:</b> Re: [cabf_validation] Validation methods used for Wildcards/ADNs<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal><o:p> </o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Tue, Feb 2, 2021 at 3:14 PM Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com">Corey.Bonnell@digicert.com</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi Ryan,<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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?<o:p></o:p></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Hi Corey,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There are several things you've gotten wrong in your message, to varying degrees, and I think this might explain the disconnect.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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)<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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).<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>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.<o:p></o:p></p></div></div></div></div></body></html>