<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On May 19, 2017, at 7:45 AM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 19, 2017 at 10:27 AM, Peter Bowen <span dir="ltr" class=""><<a href="mailto:pzb@amzn.com" target="_blank" class="">pzb@amzn.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The contention, from my view, is the definition of “data or document”. I think that all agree that a "utility bill, bank statement, credit card statement” provided by the customer in order for address verification is clearly a document and falls within the scope of this requirement. I also think all agree that data obtained from Companies House in the UK or the Division of Corporations of the State of Delaware about the existence of a company is clearly data that falls within the scope of this requirement. What is less clear or contentious is data obtained as a result of the validation process. For example, there is contention as to whether the data recorded by the CA that states that customer X controls <a href="http://p.com/" rel="noreferrer" target="_blank" class="">p.com</a> and example.aws is within the scope of the requirement. Additionally there is contention as to whether intermediate data is within the scope, such as data that shows that a Random Value was emailed to <a href="mailto:hostmaster@example.com" class="">hostmaster@example.com</a> on 2017-02-24 at 15:52 UTC and the CA received a confirming response using the Random Value on 2017-02-24 at 17:14 UTC.<br class=""></blockquote><div class=""><br class=""></div><div class="">Yes, I agree, this is a summary of the dispute with respect to 4.2.1.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Additionally I have seen some contention about the meaning of "The Random Value SHALL remain valid for use in a confirming response for no more than 30 days from its creation” as found in ballot 169. As one of he authors of this language, I intended it to mean that the confirming response must have been received within 30 days of creation of the random value, but that the response itself could be reused as per 4.2.1. That is a CA could send a random value to the domain registrant on 2017-03-01 and received the confirming response on 2017-03-05 and then use that to issue a certificate for the domain on 2017-12-29. However I think I’ve heard someone suggest that the 30 days is how long you can reuse the confirming response which would mean it could not be used to issue on 2017-12-29. This is probably another place where it would be helpful to make super clear the expectation.<br class=""></blockquote><div class=""><br class=""></div><div class="">To rephrase and confirm: As the author of that section, your understanding was that "The Random Value" constituted data obtained during validation, whose lifetime was limited to 30 days, rather than the fullness permitted under 4.2.1. You believed, however, that such usage was not in conflict with / a disruption to the existing practice under 3.2.2.4, in which the applicant, having confirmed the Random Value (and thus become a subscriber), was allowed to have multiple certificates issued using that previously completed verification, up to the limits permitted by 3.2.2.4.</div><div class=""><br class=""></div><div class="">Or did you mean to suggest that the _first_ certificate issued was issued on 2017-12-29? If so, I think I would agree - if you do not use the confirming response by 2017-03-31 (30 days) to issue a certificate, then you would not be permitted to issue on 2017-12-29.</div></div></div></div></div></blockquote><div><br class=""></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><br class=""></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" class="">https://cabforum.org/pipermail/public/2017-April/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" class="">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><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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></div><br class=""><div class="">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 class=""><br class=""></div><div class="">Thanks,</div><div class="">Peter</div></body></html>