<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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle19
        {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">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Ryan – this is a good breakdown of the issue related to changing the introductory language to many of the domain validation methods as Peter initially suggested.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I can only start (for myself) with a simple statement (or OV and EV: I think the O field in the cert should be the organization that “owns” the website where the cert will
 be used, and I think that organization should (legally) be considered the Applicant and (later) the Subscriber for purposes of all the promises and warranties we must get from the Applicant/Subscriber according to the BRs.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I don’t care if an agent
<u>who has been hired and authorized by the Applicant/Subscriber</u>, such as a web hosting company, does all the work to get the cert on the Applicant/Subscriber’s behalf – but I don’t want the web hosting company ever to be considered (legally) the “Applicant”
 or “Subscriber.”  The web hoster may have registered the domain for its customer and be listed as a contact email address in WhoIs, and so may actually click on an email to confirm the domain control for the Applicant as the agent of the Applicant, but the
 web hoster should never be considered to be the Applicant.  And I think for the most part a web hoster who clicks the CA’s Subscriber Agreement for the Applicant/Subscriber has legal authority to do so and can legally bind the Applicant/ Subscriber to the
 Subscriber Agreement terms and warranties.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I think our current BR language, including the definition of Applicant and Applicant Representative, encompasses this situation (agents acting on behalf of the website owner)
 pretty well now, so I don’t see a problem or a need for change for that situation.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Having said that, the
<u>kirk.example.com</u> example below does raise some tough questions.  I would start by saying that only the domain
<u>example.com</u> should be authenticated, and so the O field for kirk.example.com should say O= Example Corp. only.   However if there is a desire or commercial need for certs for
<u>kirk.example.com</u> where the Applicant wants O=Kirk Enterprises LLC, then we can probably accommodate that by creating some new, more restrictive vetting rules in the BRs for authenticating at third level domains or higher (where the customer does not
 want the O field information to represent the owner of the SLDN).  And if there is a problem with our rules today on this point (for example, if the wrong party is listed in the O field for example.com because of use of a practical demonstration method), let’s
 work on that.  It may not be misrepresentation by the Applicant or a bad certificate if the SLDN owner has authorized it.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">However, some responsibility or blame should extend to the owner of an SLDN if the owner allows a web hoster or other third party improperly to confirm ownership of the SLDN
 to a <u>different</u> party by using an email method or practical demonstration to misrepresent the owner to the issuing CA – the owner of the SLDN should lock down what the web hoster can do with the domain…  If the actual owner of the SLDN clicks a link
 or cooperates to show some other party as owner of the SLDN in a FQDN during domain authentication (or the web hoster does that), that’s potantially a misrepresentation to the CA that could lead to revocation of the cert if the CA finds out and does not receive
 a satisfactory explanation (such as “we have licensed the use of the domain to that other party, so it’s ok”).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Ryan Sleevi [mailto:sleevi@google.com]
<br>
<b>Sent:</b> Friday, November 20, 2015 5:07 PM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub (public@cabforum.org)<br>
<b>Subject:</b> Re: [cabfpub] FW: New subject -- Applicant/Subscriber versus domain Registrant<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">I can't help but feel this is an attempt to subtlely reintroduce the discussions we've had at length in the past - in Zurich and in Istanbul - regarding complexities of domain ownership and who the O field should represent. If you recall,
 this discussion was primarily held with respect to EV validation and wildcard certs, but as many of the participants of those discussions noted, the problems here extend both to OV/IV certs.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We can and should presume that DV, given it's lack of information about the Subscriber/Applicant beyond the domain portion, is out of scope.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">These discussions primarily used <a href="http://appspot.com">
appspot.com</a> and <a href="http://azurewebsites.net">azurewebsites.net</a> when we were discussing, mostly because Jody, Gerv and I were all discussing things.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">A few selected threads/discussions to refresh memory:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- <a href="https://cabforum.org/pipermail/public/2015-May/005623.html">https://cabforum.org/pipermail/public/2015-May/005623.html</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- <a href="https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#EV-Wildcards">https://cabforum.org/2015/10/07/2015-10-07-face-to-face-meeting-minutes-meeting-36-istanbul/#EV-Wildcards</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">- <a href="https://cabforum.org/2015/06/24/2015-06-24-face-to-face-meeting-35-minutes/">https://cabforum.org/2015/06/24/2015-06-24-face-to-face-meeting-35-minutes/</a> (search for EVWC)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">To recap those discussions, consider the following example: <a href="http://kirk.example.com">
kirk.example.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We discussed many of the parties that might be involved:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) Kirk Hall, author of the content and logical operator of the
<a href="http://kirk.example.com">kirk.example.com</a> origin<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) Example.com, provider of hosting services for Kirk Hall<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) CDN Corp, a CDN that provides SSL/TLS front-end services for
<a href="http://example.com">example.com</a>, which does not offer them directly<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4) Marketing Inc, the firm responsible for designing and maintaining the website on behalf of Kirk Hall<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5) Payments LLC, the payment processing firm responsible for handling orders and financial details on
<a href="http://kirk.example.com">kirk.example.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">6) DNS Org, the company who operates the DNS services on behalf of Kirk Hall<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">7) Mail Corp, the organization who handles the MX records that
<a href="http://kirk.example.com">kirk.example.com</a> responds to<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It is worth noting that under both the existing and proposed validation methods, any of these parties (but one) are entitled to obtain a certificate for
<a href="http://kirk.example.com">kirk.example.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">1) Can use a file-based method on <a href="http://kirk.example.com">
kirk.example.com</a>, or if control over DNS, add subrecords to establish validation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) Can use validation based on the registerable domain portion (WHOIS)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3) Can use a file-based method on <a href="http://kirk.example.com">
kirk.example.com</a> or a DNS based method<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4) Can use a file-based method or equivalent<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">5) _Cannot_ obtain a certificate, unless they can get one of the other parties to make a suitable change on their behalf to satisfy a request<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">6) Can modify the DNS or respond to email (in the case of anonymized WHOIS that provides email forwarding services)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">7) Can monitor/respond to emails as they come in<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We know that CAs - and users - employ all of these methods today with publicly trusted CAs, and have for ... well, a long time. I don't believe the goal of the VWG was or is to somehow reform these - if that's the case, then it certainly
 hasn't been clearly communicated as such, and I think there might be louder opposition if so.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">But to the problem at hand, what 'should' the information be presented as - whether this is O for OV or O for EV? As we've seen from the discussions on the calls, emails, and F2F, there isn't a clear consensus on there being 'one' right
 answer. We know that some CAs (and users) want the information presented to be who is operating the site, and we know that some CAs (and users) want it to be the person logically associated with the content. I don't think we'll resolve that here and now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think Peter's suggestions sound good, although I can fully understand and agree with your concerns that changing the language in localized parts requires thinking about how the BRs refer to things globally.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think that the best way to resolve this is:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">i) Recognize we don't have consensus yet for what the O field should present as<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ii) Recognize that the VWG proposals provide many wonderful security benefits that we shouldn't let them get hungup on resolving i)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">iii) Take a pass at the BRs, in their entirity, to find places where the language may be inconsistent with respect to the (unresolved) status quo, and update that language to reflect the present reality<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">iv) Longer term, if this is a topic members are passionate about, which I think we have evidence that some CAs are, work to build consensus as to those goals<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Before we can do iii), we need some degree of agreement on i) and ii), and I should hope that should be easy to find, but do let me know if you disagree.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On Thu, Nov 19, 2015 at 5:36 PM, <a href="mailto:kirk_hall@trendmicro.com">
kirk_hall@trendmicro.com</a> <<a href="mailto:kirk_hall@trendmicro.com" target="_blank">kirk_hall@trendmicro.com</a>> wrote:<o:p></o:p></p>
<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"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">[Reposting with permission, and responding]</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If I understand your example and concern below, you are saying the one company Company 1 may end up getting certs
 (even with the name “Company 1” in the O field for OV and EV certs) for a domain that is actually registered in WhoIs to Company 2, and Company 1 and Company 2 have no common corporate ownership and are not affiliates.  Did I simplify the facts correctly?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">And you are saying in that situation Company 1 does not “own or control” the domain belonging to Company 2, so we
 should change the wording in BR 3.2.2.4 to recognize that in the domain validation process there can be cases where the Applicant does not actually “own or control” the domain, such as the situation above.  Did I (oversimplify) that correctly?</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If I have understood your statement of the problem being addressed, I don’t think I agree with your conclusion. 
 If Company 1 is able to demonstrate practical “control” over the domain being validated by current validation methods 2-6 (or revised validation methods 2-9), then to me “ownership or control” has been demonstrated by Company 1, even if there is no obvious
 connection between the Applicant (Company 1) and the registered domain owner (Company 2).  If Company 1 can respond to one of the permitted email addresses, or can do a practical demonstration for the domain being validated, to me that is sufficient “control”
 to provide the cert.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If I have mischaracterized your comments, please excuse me.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I don’t think the current language in BR 3.2.2.4 presents any problem we need to address.  To me, the much bigger
 issue beyond the narrow wording of BR 3.2.2.4 is, who is the “Applicant”, who automatically becomes the “Subscriber” after acceptance by the CA through the rest of the BRs.  I think it
<u>must</u> be the company that owns the website (and the cert) in question – in this case, Company 1 above - and not any agent or web hoster who is handling matters for Company 1 (and also not the WhoIs Registrant in this example, Company 2). 
</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">If we add any ambiguity or flexibility to who is (or may be) the Applicant, than all the other references to the
 Applicant and later to the Subscriber in the BRs become very unclear – in that case, who are we talking about, Company 1, the web hoster, or Company 2 – or yet someone else who has helped in getting the domain validation completed?  In fact, the Applicant
 and Subscriber agree to massive obligations to the CA and to the public under the rest of the BRs (and usually in the Subscriber Agreement between the Applicant/Subscriber and the CA), and we can’t afford any ambiguity about exactly who that is in all cases,
 even if the Applicant is helped by third parties as their agents, such as web hosters.</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Peter Bowen [mailto:<a href="mailto:pzbowen@gmail.com" target="_blank">pzbowen@gmail.com</a>]
<br>
<b>Sent:</b> Thursday, November 19, 2015 5:19 PM<br>
<b>To:</b> Kirk Hall (RD-US)<br>
<b>Cc:</b> CABFPub (<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>)<br>
<b>Subject:</b> Re: [cabfpub] New subject -- Applicant/Subscriber versus domain Registrant</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Kirk,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think this has veered a little off course.  The scenario you describe is not the one I'm worried about.  Let me try to describe the scenario that I'm trying to ensure is clearly
 covered in the revised 3.2.2.4 (as it is a common scenario).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Contoso Ltd. registeres
<a href="http://contoso.com" target="_blank">contoso.com</a>.  All contacts in the whois data for
<a href="http://contoso.com" target="_blank">contoso.com</a> point to the Contoso Ltd corporate mailing address and all contact emails are
<a href="mailto:ckent@contoso.com" target="_blank">ckent@contoso.com</a>.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Fabrikam, Inc. registeres
<a href="http://fabrikam.com" target="_blank">fabrikam.com</a>.  All contacts in the whois data for
<a href="http://fabrikam.com" target="_blank">fabrikam.com</a> point to the Fabrikam, Inc coporate mailing address and all contact emails are
<a href="mailto:bwayne@fabrikam.com" target="_blank">bwayne@fabrikam.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Example Service Corporation is a service provider located in Ames, Iowa in the United States.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Contoso, Fabrikam, and Example Service Co not affiliates of each other; they share no common ownership or control.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Example Service Corporation applies for a certificate with the Subject of "/C=US/ST=Iowa/L=Ames/O=Example Service Corporation" and two dNSNames in the subjectAltName extension:
<a href="http://images.contoso.com" target="_blank">images.contoso.com</a> and <a href="http://blog.fabrikam.com" target="_blank">
blog.fabrikam.com</a>.  The CA operator first performs verification of Example Service Corporation according to the BRs.  After this completing this verification, the CA sends emails to
<a href="mailto:ckent@contoso.com" target="_blank">ckent@contoso.com</a> and <a href="mailto:bwayne@fabrikam.com" target="_blank">
bwayne@fabrikam.com</a> to validate that Example Service Corporation has approval to get a certificate with the respective FQDNs.  After each responds, the CA issues the certificate.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think that this is a fairly standard process and is compliant with the BRs today.  However the changes to 3.2.2.4 suggest that Line E (option 3) must show the "Applicant’s domain
 ownership or control".  Some auditors or relying parties might suggest that simply having the Registrant respond to the email may not prove that the Applicant is the 'owner' of the domain nor that the Applicant has control of the FQDN.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I am proposing the changes to ensure that it is clear that an email to the registrant alone is sufficient to meet the requirements.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Peter<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">(permission to repost is granted)<o:p></o:p></p>
</div>
</div>
</div>
</div>
<div>
<div>
<table class="MsoNormalTable" border="0" cellspacing="3" cellpadding="0">
<tbody>
<tr>
<td style="background:white;padding:.75pt .75pt .75pt .75pt">
<table class="MsoNormalTable" border="0" cellspacing="3" cellpadding="0">
<tbody>
<tr>
<td style="padding:.75pt .75pt .75pt .75pt">
<pre>TREND MICRO EMAIL NOTICE<o:p></o:p></pre>
<pre>The information contained in this email and any attachments is confidential <o:p></o:p></pre>
<pre>and may be subject to copyright or other intellectual property protection. <o:p></o:p></pre>
<pre>If you are not the intended recipient, you are not authorized to use or <o:p></o:p></pre>
<pre>disclose this information, and we request that you notify us by reply mail or<o:p></o:p></pre>
<pre>telephone and delete the original message from your mail system.<o:p></o:p></pre>
</td>
</tr>
</tbody>
</table>
</td>
</tr>
</tbody>
</table>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
_______________________________________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><o:p></o:p></p>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>

<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>