<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Apr 16, 2017 at 1:13 PM, Peter Bowen <span dir="ltr"><<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>></span> wrote:<br><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><div>Previous versions could be used as they are “Completed confirmations”. There is nothing that says the completed confirmation has to have been created using a process described in the current BRs.<br></div></div></div></blockquote><div><br></div><div>Nothing says they could use previous versions.</div><div><br></div><div>In the absence of such a statement, "completed confirmation" must be read to be consistent with the in-force version of the Baseline Requirements (i.e. excluding previous versions), as a certificate issued using a previous version's confirmation has not been issued in accordance with 7.1.4.2 or 3.2.2.4.</div><div><br></div><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><div>I would also point out that 4.2.1 is not the section that requires following 3.2.2.4; under 4.2.1 the CA could simply call the customer to confirm they requested the data be included. </div></div></div></blockquote><div><br></div><div>Oh for sure, but 4.2.1 governs the maximum age of reuse.</div><div> </div><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>Could we maybe split validation of namespaces from server auth certificate issuance?  We already have clear definitions of namespaces for subject names (both the Subject Name itself as well as Subject Alternative Names) defined in Name Constraints.  What if we simply required that each Name in a certificate (whether Distinguished Name, DNS Name, IP Address, RFC 822 Name, or SRV name) fall within a validated namespace and that the certificate must expire prior the the expiration of any namespace validation relied upon for issuance of the certificate?  This would clearly allow a company to use a time consuming but high assurance validation process (e.g. identity validation + registration match + legal agreement) and then get multiple short lived certificates using that validation.</div></div></blockquote><div><br></div><div>So in general, I think this is clearly the intent of some proponents, and is more directly stated than past attempts, so I appreciate that. My concern is and remains how we bound the maximum age of that data (so as to ensure out of date information is not relied upon for a time longer than is reasonable) and how that data is invalidated (for example, to avoid a situation where a revocation event occurs and the CA continues to use the previously validated information, as we've already seen some CAs unfortunately do).</div><div><br></div><div>Do you have a sense of what you believe the upper-bound for such information can or should be?</div></div></div></div>