<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 Apr 14, 2017, at 1:47 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" class="">public@cabforum.org</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, Apr 14, 2017 at 4:30 PM, Jeremy Rowley <span dir="ltr" class=""><<a href="mailto:jeremy.rowley@digicert.com" target="_blank" class="">jeremy.rowley@digicert.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" class=""><div class="gmail-m_-6131725752303443664WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif" class="">Thanks a ton Ryan for putting this together. This is great info.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif" class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><a name="m_-6131725752303443664__MailEndCompose" class=""><span style="font-size:11pt;font-family:calibri,sans-serif" class="">I agree the BRs are missing a re-use of information section, which is odd because the section exists in the EV Guidelines (11.14.1 and 11.14.2).</span></a></p></div></div></blockquote><div class=""><br class=""></div><div class="">That's nominally covered in Section 3.2.2.4 as part of the introduction, but it doesn't allow for "previous" versions to be used.</div><div class=""><br class=""></div><div class="">Specifically,</div><div class=""><br class=""></div><div class="">"Completed<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>confirmations<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>of<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Applicant<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>authority<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>may<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>be<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>valid<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>for<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>issuance<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>of<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>multiple<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>certificates<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>over<span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div class="">time.<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>In<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>all<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>cases,<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>confirmation<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>must<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>have<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>been<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>initiated<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>within<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>time<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>period<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>specified<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>in<span style="white-space:pre" class=""> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>relevant<span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div class="">requirement<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>(such<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>as<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Section<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>3.3.1<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>of<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>this<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>document)<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>prior<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>to<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>certificate<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>issuance.<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>For<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>purposes<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>of<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>domain<span class="gmail-Apple-tab-span" style="white-space:pre"> </span></div><div class="">validation,<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>term<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Applicant<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>includes<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>the<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Applicant's<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Parent<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Company,<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Subsidiary<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Company,<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>or<span class="gmail-Apple-tab-span" style="white-space:pre"> </span>Affiliate.<span class="gmail-Apple-tab-span" style="white-space:pre"> “</span></div></div></div></div></div></blockquote><div><br class=""></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.</div><div><br class=""></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. Section 7.1.4.2 is what requires validation:</div><br class="">"By issuing the Certificate, the CA represents that it followed the procedure set forth in its Certificate Policy<br class="">and/or Certification Practice Statement to verify that, as of the Certificate’s issuance date, all of the Subject<br class="">Information was accurate. CAs SHALL NOT include a Domain Name or IP Address in a Subject attribute<br class="">except as specified in Sections 3.2.2.4 or 3.2.2.5.”</div><div><br class=""></div><div><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><span style="font-family:calibri,sans-serif;font-size:11pt" class=""> </span><span style="font-family: calibri, sans-serif; font-size: 11pt;" class="">I was planning on circulating the following proposal to sync the two requirement docs once the number of pending ballots declined:</span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US" class=""><div class="gmail-m_-6131725752303443664WordSection1"><p class="MsoNormal"><span class=""><span style="font-size:11pt;font-family:calibri,sans-serif" class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class="">Add the following to 3.3.1 (taken from 11.14.2 of the EV Guidelines):<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">A CA may rely on a previously submitted certificate request to issue a new certificate if: <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(1) The expiration date of the replacement certificate is the same as the expiration date of the Certificate being replaced, and <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(2) The Subject Information of the Certificate is the same as the Subject in the Certificate that is being replaced.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><u class=""></u> <u class=""></u></span></p><p class="MsoNormal"><span class="">Add the following to 4.2.1 (sort of taken from 11.14.1) after the third paragraph: <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">If an Applicant has a currently valid Certificate issued by the CA, a CA MAY rely on the prior authentication and verification of: <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(1) The Applicant's identity under Section 3.2.2.1; <u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(2) The Applicant’s DBA under Section 3.2.2.2;<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(3) The countryName under Section 3.2.2.3;<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(4) The Applicant’s individual identity under Section 3.2.3; and<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class="">(5) The Applicant’s authorization to issue the Certificate under Section 3.2.5, provided that the CA receives or confirms the request for a Certificate using a Reliable Method of Communication.<u class=""></u><u class=""></u></span></p><p class="MsoNormal"><span class=""><span style="font-size:11pt;font-family:calibri,sans-serif" class=""><u class=""></u> <u class=""></u></span></span></p><p class="MsoNormal"><span class=""><span style="font-size:11pt;font-family:calibri,sans-serif" class="">Thoughts?</span></span></p></div></div></blockquote><div class=""><br class=""></div><div class="">I suppose it comes as no surprise that I'm in favor of more verifications, not less, and always to the current Guidelines :)</div><div class=""><br class=""></div><div class="">There are some real issues with that language in the EVGs, and I'd love to see that stricken.</div><div class=""><br class=""></div><div class="">For example, given a certificate issued for 39 months, and a request comes in at 38 months, how long can the certificate be valid? I think your intent would be to say "1 month", but I don't think the proposed change would accomplish that. Instead, I fear it would/could allow for 39 months (and then 77 months since the original validation, another 39 month cert be issued)</div></div></div></div></blockquote><br class=""></div><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><br class=""></div><div>Thanks,</div><div>Peter</div></body></html>