<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.gmail-
{mso-style-name:gmail-;}
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><a name="_MailEndCompose">Ryan,<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'>I agree that a full request needs to be made before a certificate can be issued. Section 4.1.2 might adequately define a request, but I suppose someone could improve it with additional definition and/or guidance in this regard. I would not want to say for certain when a full request has been made, and indeed there is the potential for confusion with the term “Certificate Signing Request”. At some point during the process the applicant is supposed to make a representation to the CA that they are submitting accurate information. Sometimes this can be implied when a “submit button” is pressed. Another component to consider might be the Terms of Use, Subscriber Agreement, etc., that is agreed to and required by Section 4.1.2. Another complicating situation is the API process – it may be that a “request” occurs, in the course of dealing between the CA and the Subscriber, when data of a certain format is submitted to the CA. A master agreement can govern when these two documents (the request and agreement) are delivered to the CA. This is generally how EDI arrangements have worked. <o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>With regard to timing and the sequence of events, I would think that it shouldn’t matter too much as long as the steps comply with and meet the Baseline Requirements. In other words, a CA should take steps to ensure that the applicant has control of the private key, that the applicant owns or controls the domain/FQDN, that the Applicant has made the request for a certificate, etc. This is supported by the fact that the certificate request only has to be collected “prior to the issuance of a Certificate”. BR </span><span style='mso-bookmark:_MailEndCompose'>§</span><span style='mso-bookmark:_MailEndCompose'> 4.1.2.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>Finally, if your argument is that under section 4.1.2 an Applicant can’t attest to the accuracy of information not yet completed/collected, then what about the fact that the CA is given discretion to define the forms by which information is collected? Another part of section 4.1.2 allows this flexibility-- “Prior to the issuance of a Certificate, the CA SHALL obtain from the Applicant a certificate request in a form prescribed by the CA and that complies with these Requirements.” This latter provision could be improved by stating “in a form and manner …”.<o:p></o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'><o:p> </o:p></span></p><p class=MsoNormal><span style='mso-bookmark:_MailEndCompose'>Ben</span><span style='mso-bookmark:_MailEndCompose'><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> Ryan Sleevi [mailto:sleevi@google.com] <br><b>Sent:</b> Friday, May 19, 2017 4:26 PM<br><b>To:</b> Ben Wilson <ben.wilson@digicert.com><br><b>Cc:</b> CA/Browser Forum Public Discussion List <public@cabforum.org>; Peter Bowen <pzb@amzn.com><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>I think the question is not whether it's "common", it's whether and where it's even permitted :)<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I mentioned the sections that define what constitutes what an Applicant must suggest as part of a certificate request, and a certificate request is what makes them an applicant. It sounds like the suggestion being made here is that 'part' of a certificate request can be submitted, and then, later, and some other point, the 'full' certificate request can be made, thus meeting the obligations.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>My point, particularly in the context of Section 4.1.2, is what constitutes the absolute minimum for a request. 4.1.2 spells out a certain minimum, namely:<o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>"The certificate request MUST contain a request from, or on behalf of, the Applicant for the issuance of a Certificate, and a certification by, or on behalf of, the Applicant that all of the information contained therein is correct."</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>Do you believe that your Step 1.a meets this obligation, thus making the list of domains a Certificate Request?</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>If so, what do you call the thing they submit in Step 3?</span><o:p></o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>If not, what do you believe permits Step 2 from starting, if a valid Certificate Request is not required?</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>This is how you get into the situation I provided, which I think is an important question to answer, since it logically emerges as permitted, if the "Certificate Request" is not done until Step 3, but you can begin validating in Step 2. There's nothing, for example, to prohibit you from starting Step 4 before Step 3 - and, indeed, Section 4.2.1 explicitly permits the CA to obtain that information independent of the customer's CSR - specifically:</span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal><span style='font-size:9.5pt'>"In cases</span> <span style='font-size:9.5pt'>where</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>certificate</span> <span style='font-size:9.5pt'>request</span> <span style='font-size:9.5pt'>does</span> <span style='font-size:9.5pt'>not</span> <span style='font-size:9.5pt'>contain</span> <span style='font-size:9.5pt'>all</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>necessary</span> <span style='font-size:9.5pt'>information</span> <span style='font-size:9.5pt'>about</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>Applicant,</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>CA SHALL</span> <span style='font-size:9.5pt'>obtain</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>remaining information</span> <span style='font-size:9.5pt'>from</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>Applicant</span> <span style='font-size:9.5pt'>or,</span> <span style='font-size:9.5pt'>having</span> <span style='font-size:9.5pt'>obtained</span> <span style='font-size:9.5pt'>it</span> <span style='font-size:9.5pt'>from</span> <span style='font-size:9.5pt'>a</span> <span style='font-size:9.5pt'>reliable, independent,</span> <span style='font-size:9.5pt'>third‐party</span> <span style='font-size:9.5pt'>data</span> <span style='font-size:9.5pt'>source,</span> <span style='font-size:9.5pt'>confirm</span> <span style='font-size:9.5pt'>it</span> <span style='font-size:9.5pt'>with</span> <span style='font-size:9.5pt'>the</span> <span style='font-size:9.5pt'>Applicant." </span><o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Or, put differently, based on what you described as "common practice", if we accept that it's also "permitted" practice, then it's fully permitted to reorder the sequence you describe as:<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>4 – CA completes any remaining validation steps and verifies that process has not exceeded any applicable timeframes<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>1 – a. Customer signs a contract with domains listed therein, or<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:.5in'>b. signs up for an account, obtains a username/password and submits domain names.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>2 – CA starts the domain validation process<o:p></o:p></p></div><div><p class=MsoNormal>3 – Customer submits CSR<o:p></o:p></p></div><div><div><div><p class=MsoNormal>5 – CA issues certificate<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Is it clear how I arrive at that conclusion?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On Fri, May 19, 2017 at 6:15 PM, Ben Wilson <<a href="mailto:ben.wilson@digicert.com" target="_blank">ben.wilson@digicert.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'><a name="m_8890707220655629521__MailEndCompose">Pre-validation is a common practice. Here is scenario:</a><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'>1 – a. Customer signs a contract with domains listed therein, or <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:.5in'>b. signs up for an account, obtains a username/password and submits domain names.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>2 – CA starts the domain validation process<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>3 – Customer submits CSR<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>4 – CA completes any remaining validation steps and verifies that process has not exceeded any applicable timeframes<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>5 – CA issues certificate <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;margin-bottom:2.0pt'><b><span style='font-family:"Arial",sans-serif;color:#0174C3'>Ben Wilson, JD, CISA, CISSP</span></b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:2.0pt'><span style='font-family:"Arial",sans-serif;color:#686869'>VP Compliance</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:2.0pt'><span style='font-family:"Arial",sans-serif;color:#686869'><a href="tel:(801)%20701-9678" target="_blank">+1 801 701 9678</a></span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><img border=0 width=133 height=29 style='width:1.3833in;height:.3041in' id="gmail-m_8890707220655629521Picture_x0020_1" src="cid:image002.jpg@01D2D0C3.1FA36DD0"><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'><span class=gmail-><b>From:</b> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>] <b>On Behalf Of </b>Ryan Sleevi via Public</span><br><b>Sent:</b> Friday, May 19, 2017 4:08 PM<br><b>To:</b> Peter Bowen <<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>><br><b>Cc:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [cabfpub] Preballot - Revised Ballot 190<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><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 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'>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 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'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 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'>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 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'>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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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 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'>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 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'>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 style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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></div></div></div></blockquote></div><p class=MsoNormal><o:p> </o:p></p></div></div></div></div></div></body></html>