<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 19, 2017 at 11:39 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>There is another way to look at it.  Applicant is a defined term that is basically a pronoun.  It is reasonable to replace the capitalized “Applicant” with a specific natural person or legal entity.  So the 3.2 validations can be performed against a specific legal entity — e.g. Aperture Science, Inc.  Given that completed validations can be reused, it stands that one could validate that Aperture Science, Inc. controls <a href="http://example.com" target="_blank">example.com</a>, then use that later to issue a certificate.  I think you are getting hung up on a concept that the only way to resolve “Applicant” to a specific entity is via the Applicant submitting a certificate request.  I don’t see anything that forbids a CA from validating that a natural person or legal entity controls a domain or exists outside of a request then reusing that to satisfy a future future validation request.</div></div></blockquote><div><br></div><div>It's actually that scenario that I'm concerned about, because if we remove the notion of 'a request' from being tied to 'an applicant', then we've also removed all the triggers for validating information in the context of 'a request'.</div><div><br></div><div>My simplified concern is making sure we always have a clear and unambiguous definnition of "An Applicant", and the triggers for validation - namely, "A Request". I think decoupling these introduces a whole host of issues, least among them the possibility for bugs (which some CAs have already manifest) in which the use of information is tied to the date of the first 'request', even if the documents were obtained prior.</div></div></div></div>