<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 5:16 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>It was my intent and understanding that the 30 days had nothing to do with 4.2.1 or 3.2.2.4’s reuse requirements or allowances.  We wanted to limit how long a validation could be in a “pending” state. Therefore we added a constraint on the delta between the time the confirmation was received and the time the random value was generated.  As long as the CA recorded when the Random Value was created, recorded when the confirming response was received, and those were not more than 30 days apart, the data could be reused months or even years later.  </div></div></div></blockquote><div><br></div><div>Ah, I see, on the basis that by confirming the reception of the random value - and thus completing all the necessary steps of 3.2.2.4.[method using random value] - this act constitutes a "completed confirmation of Applicant authority" (with respect to 3.2.2.4's reuse)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div>You also seem to hint at another possible point of contention.  There appears to be a possible disagreement as to whether CAs have to follow a specific order of processing for certificate requests.  Notably, in <a href="https://cabforum.org/pipermail/public/2017-April/010539.html" target="_blank">https://cabforum.org/<wbr>pipermail/public/2017-April/<wbr>010539.html</a>, Ryan described an possible order.  However some CAs have described a different order, wherein the customer initiates the request saying “we will be requesting a certificate for <a href="http://example.com" target="_blank">example.com</a>”, then the CA validates the domain, then the customer submits the CSR and other required information necessary to complete the request.  The duration between the initial steps (through domain validation) and the latter steps can be considerable — possibly months apart.  This is what some have called domain “pre-validation”.  I think some have suggested that the BRs don’t allow this alternative order of operations, but I’m having a little trouble finding the specific cite.  Do you, Ryan, or does anyone else, think the order of operations described above is not valid?</div></div></div></blockquote><div><br></div><div>I think we're in agreement that the Applicant must initiate the request in some form. I called that out in the previous message - that in some manner, a request must be generated.</div><div><br></div><div>1.3.2 implies that a request includes the Subject name, and by proxy, the domain names. We can also conclude it includes additional data (e.g. see Section 3.2.3), and more explicitly spelled out by 4.1.2.</div><div><br></div><div>"The<span style="white-space:pre">     </span>certificate<span style="white-space:pre">  </span>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."</div><div><br></div><div>On the basis of this, I would suggest that a "We will be requesting a certificate for <a href="http://example.com">example.com</a>" does not in and of itself constitute a certificate request. It may be that the request is _only_ for the binding of the domain, but I'm not sure that would be a valid request, under both 4.1.2 and 4.2.1. Now, assuming the request holds at least a domain and public key, arguably it meets the definition of 4.2.1, and all other factual information about the Applicant to be included (e.g. in the case of OV/EV) can be obtained out of band, consistent with 4.2.1</div><div><br></div><div>Does that help provide the cite?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="gmail-"><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I do want to stress the flexibility and openness to consider interpretations so that we harmoniously align, despite the deep concerns about the security implications and the practices of some CAs, provided that we find an appropriate route to transparently quantify and assess the certificates, so that it is possible for relying parties to distinguish these issues.</div></div></div></div>
</div></blockquote></span></div><br><div>I think our objective should be to get to a common understanding for all.  The BRs have historically been a consensus document, setting the minimum requirements.  CAs are welcome to go above and beyond.  Where there is contention, we should clarify, but the focus should not necessarily be on raising the security bar, rather we should document where we are first, then discuss raising it.</div></div></blockquote><div><br></div><div>Indeed. But we certainly should provide proactive ways for CAs to assert conformance to a higher level, much as we allow CAs to attest a more rigid validation with respect to EV certificates. </div></div></div></div>