<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)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><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;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
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><div class=WordSection1><p class=MsoNormal><a name="_MailEndCompose">Pre-validation is a common practice. Here is scenario:<o:p></o:p></a></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>1 – a. Customer signs a contract with domains listed therein, or <o:p></o:p></span></p><p class=MsoNormal style='text-indent:.5in'><span style='mso-bookmark:_MailEndCompose'>b. signs up for an account, obtains a username/password and submits domain names.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>2 – CA starts the domain validation process<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>3 – Customer submits CSR<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>4 – CA completes any remaining validation steps and verifies that process has not exceeded any applicable timeframes<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>5 – CA issues certificate <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal style='margin-bottom:2.0pt'><span style='mso-bookmark:_MailEndCompose'><b><span style='font-family:"Arial",sans-serif;color:#0174C3'>Ben Wilson, JD, CISA, CISSP<o:p></o:p></span></b></span></p><p class=MsoNormal style='margin-bottom:2.0pt'><span style='mso-bookmark:_MailEndCompose'><span style='font-family:"Arial",sans-serif;color:#686869'>VP Compliance<o:p></o:p></span></span></p><p class=MsoNormal style='margin-bottom:2.0pt'><span style='mso-bookmark:_MailEndCompose'><span style='font-family:"Arial",sans-serif;color:#686869'>+1 801 701 9678<o:p></o:p></span></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><img width=133 height=29 style='width:1.3875in;height:.3in' id="Picture_x0020_1" src="cid:image001.jpg@01D2D0BB.126EAAB0"><o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><span style='mso-bookmark:_MailEndCompose'></span><p class=MsoNormal><b>From:</b> Public [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi via Public<br><b>Sent:</b> Friday, May 19, 2017 4:08 PM<br><b>To:</b> Peter Bowen <pzb@amzn.com><br><b>Cc:</b> Ryan Sleevi <sleevi@google.com>; CA/Browser Forum Public Discussion List <public@cabforum.org><br><b>Subject:</b> Re: [cabfpub] Preballot - Revised Ballot 190<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, May 19, 2017 at 6:00 PM, Peter Bowen <<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.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'><p class=MsoNormal>Yes, it does. We know that CAs can generate keys on behalf of the subscriber, so it is clear that a public key is not required. This means that a CA could take the request for “issue a certificate to <a href="http://example.com" target="_blank">example.com</a>”, do validation and key generation, throw away the private key, issue the cert, and end up with a “pre-validated” domain. This is compliant. The generated cert could have some flag in it, similar to a pre-cert, that makes it unusable for any real world purpose, and it would still be fine. But this is silly. We don’t want to have hoop jumping for no discernible value.<br><br>Can you suggest a change that you feel would make it clear that CAs may validate identities (organizations, domains, etc) independent of issuing certificates and use the documents and data gathered during such validation for future issuance, subject to the aging requirement of 4.2.1? I would suggest a change myself, but I’m not quite clear which part of the BRs you feel prevents this today.<o:p></o:p></p></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>The BRs are gated on the concept of an Applicant - all of the validation is done in concert and connection with an Applicant.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I'm not sure how it makes sense for CAs to have, say, a prevalidated set of organizations, any of which can apply and thus reuse the information.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Put differently: Do you think it would be BR conformant if a CA looked through CT, determined which organizations had OV/EV certs, worked through QIIS/QGIS's to 'prevalidate' the organizational information related to it, and then approached all customers with the remark "We can give you a certificate in 30 seconds?"<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>It may be that the answer is yes - that the extent of the CAs obligations (to validate the documents and domain, in absentia of an Applicant) are met.<o:p></o:p></p></div><div><p class=MsoNormal>It may be that the answer is no - that a CA cannot begin doing some form of validation until contacted by an Applicant.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>But I think understanding the specific answer to this scenario can help inform whether or not an "Applicant" is required to make a certificate request before being, well, an "Applicant".<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>If they are required to make a request, then naturally, it follows that your so-called hoop-jumping is necessary, since there is a minimum definition of what constitutes a certificate request.<o:p></o:p></p></div><div><p class=MsoNormal>If they are not required to make a request, then naturally, the scenario I described is the logical extreme, in which the CA can validate 'everything but the application'. To further add to the extreme, it might be possible for the CA to pre-generate the public key, and just call up the subscriber and say "Do you want a cert" - with that assent being sufficient to constitute an "Application"<o:p></o:p></p></div></div></div></div></div></body></html>