<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:"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-size:10.0pt;
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;}
--></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>> However, I'm not sure I understand your dismissal of my previous reply, as that's how this message comes across. The fact that several CAs are actively encouraging or promoting their users to use the HTTP-based methods for wildcard certificates, without any acknowledgement of the long-established security risks, is fundamentally concerning. Members have, in the past, objected to when I specifically call out CAs engaged in such practices, but if the request is "name and shame", and members feel it's appropriate, I'm happy to do so.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>My previous message was not a dismissal of the concern, but rather a request for clarification as StartCom/WoSign was mentioned but HTTP-based “ADN != FQDN” validation was not relevant to the security issues for that CA. Given your previous responses, it sounds like the motivation for this discussion is not to address a recently discovered vulnerability that has become known regarding HTTP-based domain validation, but instead to continue the long-standing work of this group. Is this an accurate assessment?<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> Do you agree that HTTP-based methods fundamentally do not demonstrate control or authorization of subdomains? If you believe they consistently and universally do so, I'm hoping you can articulate how. If the response is "They don't, but maybe that's not an issue", then it might be better if you clearly stated that's your belief.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Each domain validation method describes a delegation stemming from DNS to allow Applicants to assert control of a given domain (and potentially subdomains). These various forms of delegation provide Applicants flexibility so they can perform domain validation and obtain certificates in a variety of configurations. For example, method 18/19 is a delegation of authority from the DNS controller to validate a domain name (and its subdomains) via a A/AAAA record to an HTTP server running under the machine administrator account (since we require privileged ports). This is an issue if a DNS administrator is unaware that a record allows the administrator of the server machine to obtain certificates both for the given domain name and its subdomains.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Method 7 can be performed with no such delegation; the domain validation challenge data is generally stored directly in the DNS zone that contains the FQDN. That intuitively is easier for DNS administrators to understand so that authorization to issue certificates is not inadvertently granted. However, this is not universally the case as method 7 allows for underscore-prefixed subdomains to validate the parent domain. Additionally, there is no requirement that this underscore-prefixed subdomain ADN even be in the same zone as the parent FQDN. In a similar vein to method 18/19, this is a delegation of authority that DNS administrators need to be aware of.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>These methods have long had these security properties, as evidenced by the discussion in various mailing lists and customer-facing documentation provided by many long-standing CAs. Thus, the ecosystem has aligned its operational practices to account for these validation methods. So, to answer your question, my current line of thinking is “They don’t, but maybe that’s not an issue”. Method 7 does utilize the same namespace that is being validated, which seemingly would provide superior security properties over method 18/19, but its provision where a ADN subdomain can validate a parent FQDN makes it similar to the delegation model of method 18/19.<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><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> Wednesday, February 3, 2021 12:50 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 Wed, Feb 3, 2021 at 12:27 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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><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'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>> 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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'll see if I can dig up from the management@ archives, since searching is ... sub-optimal.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, I'm not sure I understand your dismissal of my previous reply, as that's how this message comes across. The fact that several CAs are actively encouraging or promoting their users to use the HTTP-based methods for wildcard certificates, without any acknowledgement of the long-established security risks, is fundamentally concerning. Members have, in the past, objected to when I specifically call out CAs engaged in such practices, but if the request is "name and shame", and members feel it's appropriate, I'm happy to do so.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>However, I cannot help but feel that your line of questioning is trying to dismiss there being any security concerns, including those long-established here in the Forum, even by the validation WG itself. If that's not your intent, I'm hoping you can clarify: Do you agree that HTTP-based methods fundamentally do not demonstrate control or authorization of subdomains? If you believe they consistently and universally do so, I'm hoping you can articulate how. If the response is "They don't, but maybe that's not an issue", then it might be better if you clearly stated that's your belief.<o:p></o:p></p></div></div></div></div></body></html>