<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:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* 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.EmailStyle18
{mso-style-type:personal-reply;
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;}
--></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">(Moving this discussion to the validation subcommittee mailing list)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Hi Aaron<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I find your proposal for clarifying that the use of a third-party DNS Resolver is forbidden in Section 3.2.2.4 to address what I have been missing in the BRs. <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I would also like to follow up your statement related to that CAs might unknowingly use DTPs for domain validations, by using third-party email providers (e.g. Mailchimp and Sendgrid). I suggest we discuss whether using cloud-based email
services for domain validation in general is problematic. And if that is problematic, if only on-premises SMTP servers should be accepted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Another topic I would like to address is the use of WHOIS-lookups for domain validations.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In the BR, I find the following definitions:<o:p></o:p></p>
<p class="MsoNormal"><b>Domain Contact:</b> The Domain Name Registrant, technical contact, or administrative contact (or the equivalent under a ccTLD) as listed in the WHOIS record of the Base Domain Name or in a DNS SOA record, or as obtained through direct
contact with the Domain Name Registrar.<o:p></o:p></p>
<p class="MsoNormal"><b>WHOIS</b>: Information retrieved directly from the Domain Name Registrar or registry operator via the protocol defined in RFC 3912, the Registry Data Access Protocol defined in RFC 7482, or an HTTPS website.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The registry operator is the authoritative source and therefore acceptable. I assume that
<u>the</u> Domain Name Registrar must be the registrar responsible for registering the actual domain, but this is not very clear. CAs may use the WHOIS protocol and the RDAP protocol for such lookups directly against those actors, but is using an HTTPS website
unproblematic? Some examples for .com domains would be nice.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In BR 3.2.2.4.2 we find ‘<i>The Random Value MUST be sent to an email address identified as a Domain Contact’</i>. In addition, we find ‘<i>The CA may send the email to more than one recipient provided that every recipient is identified
by the Domain Name Registrar as representing the Domain Name Registrant’</i>. Does this mean that this is only allowed if the Domain Contacts are provided by the Domain Name Registrar, and is this intentional? <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Regards<o:p></o:p></p>
<p class="MsoNormal">Mads <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> Public <public-bounces@cabforum.org> <b>On Behalf Of
</b>Aaron Gable via Public<br>
<b>Sent:</b> Thursday, January 11, 2024 5:54 PM<br>
<b>To:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; CA/Browser Forum Public Discussion List <public@cabforum.org><br>
<b>Subject:</b> Re: [cabfpub] Highlight repeated non-acceptable practices, clarify requirements and discuss about DTPs<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">For the sake of discussion, here's a concrete proposal for how to easily clarify that use of a public (third-party) DNS resolver is forbidden:<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Add to Section 3.2.2.4, immediately after the two numbered sentences:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">"All DNS queries conducted in the course of validation MUST be made from the CA to authoritative nameservers, i.e. without the use of recursive resolvers operated by third parties."<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">This proposal does not address the possibility that we could establish a lightweight audit scheme that third-party recursive resolvers could satisfy to be allowed. It also does not address the possibility that CAs are unknowingly using
delegated third parties for other aspects of domain validation, such as Mailchimp / Sendgrid for sending emails. But it's a starting point to kick off discussion.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Aaron<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Dec 27, 2023 at 11:09 PM Dimitris Zacharopoulos (HARICA) via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</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">
<p class="MsoNormal"><br>
Dear Members,<br>
<br>
While monitoring a specific recent bugzilla incident, I realized that it <br>
is very easy to unintentionally misinterpret some parts within the Forum <br>
Guidelines that can lead to compliance problems. I think it is our <br>
obligation as a Forum to monitor compliance issues reported by CAs or <br>
independent researchers and in case of repeated incidents, suggest <br>
clarification language in the Forum's Guidelines. Nobody wants more <br>
incidents, but a repeated pattern doesn't necessarily mean negligence on <br>
the CA's part. It could very well be that the Guidelines are not well <br>
written in some areas.<br>
<br>
In that regard, I would strongly encourage our Certificate Consumer <br>
Members, that continuously review and monitor incidents, to search for <br>
common patterns and try to locate the language in the Forum Guidelines <br>
that might be somewhat unclear, and work on improving those parts. Even <br>
if the language seems "clear enough", for cases that have caused <br>
multiple incidents by multiple CAs, it might be worth to add NOTES or <br>
NOTICES to highlight non-acceptable practices that have been <br>
misunderstood my multiple CAs.<br>
<br>
The Delegated Third Party concept is understandably very open and not <br>
very well defined. I recommend all WGs to try and clarify how DTPs could <br>
be used in the certificate lifecycle process, including <br>
Domain/Identity/Email Validation but also in the supporting <br>
infrastructure services like compute, storage, network, backup, WHOIS, <br>
DNS, Email, regular post, SMS, and more. Perhaps this is a task for the <br>
Network Security Working Group but some elements are specific to other WGs.<br>
<br>
My recommendation to all WGs is that when we see repeated patterns of <br>
practices that, by consensus, are not acceptable and do not meet the <br>
spirit and language of the Guidelines, try to highlight them in a type <br>
of "practices clarification" ballot series.<br>
<br>
Best wishes for a Happy New Year to all!<br>
<br>
<br>
Dimitris.<br>
CA/B Forum Chair<br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/public" target="_blank">https://lists.cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</body>
</html>