<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 1, 2017 at 4:50 PM, Ryan Sleevi <span dir="ltr"><<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.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 dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>It's unclear whether you disagree with the substance of my analysis, and are thus stating it was intentional to weaken the Baseline Requirements, or if you're simply providing clarification for the intent, for which the weakening of the Baseline Requirements was unintentional?<br></div><div><br></div><div>If this was unintentional, we can work to resolve this in a way that achieves the intended resolve. However, if this was intentional, we will continue to disagree, and thus will find it necessary to vote against this ballot. I can only hope that, like Ballot 188, this was merely an unintentional side-effect, and hopefully one we can resolve through collaboration.<br></div></div></div></div>
</blockquote></div><br></div><div class="gmail_extra">It was pointed out that my description of the issues may not have been clear for some members, so I'll try to restate the various ways in which this proposal, whether intentional or not, weakens the current security guarantees provided by the Baseline Requirements.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the effort of providing greater clarity, I have created several new threads to help inform this discussion.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Current Section 4.2.1</div><div class="gmail_extra"><div class="gmail_extra">"Section 6.3.2 limits the validity period of Subscriber Certificates.   The CA MAY use the documents and data </div><div class="gmail_extra">provided in Section 3.2 to verify certificate information, provided that the CA obtained the data or document </div><div class="gmail_extra">from a source specified under Section 3.2 no more than thirty‐nine (39) months prior to issuing the Certificate"</div></div><div class="gmail_extra"><br></div><div class="gmail_extra">Proposed for Section 4.2.1</div><div class="gmail_extra">Section 6.3.2 limits the validity period of Subscriber Certificates. The CA MAY use the documents and data provided in Section 3.2 to verify certificate information, provided that (i) the CA obtained the data or document from a source specified under Section 3.2 no more than 825 days thirty‐nine (39) months prior to issuing the Certificate; and (ii) the method used to obtain the document or data was acceptable under Section 3.2 at the time the document or data was obtained.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Problem Summary: This allows CAs to bypass checking the accuracy of Subscriber information, including authorized domain names when reissuing certificates. While this may be desirable by CAs that wish to be lax in what they issue, it is not permitted under the current Baseline Requirements.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Explanation: The current Section 4.2.1 limits the reuse of information to "data or document from a source specified under Section 3.2". It appears that some CAs have interpreted this to describe both the data and the procedure of verifying that data, but that's not what is currently stated. That is, Section 4.2.1 only permits the reuse of information. In some cases, the mere existence of this data or documentation may be sufficient to constitute the verification process. For example, Section 3.2.2.2 regarding DBA/Tradenames describes that "the CA SHALL verify the Applicant's right to use the DBA/tradename using at least one of the following". In this case, the source of the data is equivalent to verifying the data, modulo the stipulations set forth in 3.2.2 regarding the CA's obligation to inspect any document for alteration or falsification.</div><div class="gmail_extra"><br></div><div class="gmail_extra">However, in other cases, the act of obtaining data and documentation is distinct from that of verifying. For example, Section 3.2.2.4 notes that "The CA SHALL confirm that, as of the date the Certificate issues, either the CA or a Delegated Third Party has validated each Fully‐Qualified Domain Name (FQDN) listed in the Certificate using at least one of the methods listed below.". In this case, this poses a continual validation requirement - every certificate must be validated. In recognizing this, the immediate next paragraph of Section 3.2.2.4 notes "Completed confirmations of Applicant authority may be valid for the issuance of multiple certificates over  time. In all cases, the confirmation must have been initiated within the time period specified in the relevant requirement (such as Section 3.3.1 of this document) prior to certificate issuance."</div><div class="gmail_extra"><br></div><div class="gmail_extra">The above highlights an example where obtaining data is distinct from the act of validating that data. This is further reaffirmed using 3.2.2.4.6 as an example, which provides a special proviso regarding Agreed-Upon Change to a Website, noting "If a Random Value is used, the CA or Delegated Third Party SHALL provide a Random Value unique to the  certificate request and SHALL not use the Random Value after the longer of (i) 30 days or **(ii) if the Applicant  submitted the certificate request, the timeframe permitted for reuse of validated information relevant to the  certificate (such as in Section 3.3.1 of these Guidelines or Section 11.14.3 of the EV Guidelines).** " (Emphasis in ** added)</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">Example: Imagine that the Baseline Requirements, version 1.0.0, Section 3.2.2.2, listed an additional method, "6. By obtaining an assertion from Ryan Sleevi that the information is correct". A certificate issued during the 'Effective' period of Version 1.0.0, with my explicit approval regarding the DBA/tradename, would this be compliant with the Baseline Requirements. Recognizing, however, that I am a flawed individual, imagine that the CA/B Forum adopts version 1.1.0 of the Baseline Requirements, which removes this method. At the time of certificate issuance, the CA MUST verify the Applicant's right to the DBA/tradename. Despite my previous approval, completed within the 39 month window, this method is no longer acceptable in version 1.1.0. Thus if a certificate is issued for a DBA/tradename, relying on my prior assertion, it would be in violation of the Baseline Requirements.</div><div><br></div></div><div class="gmail_extra">Conclusion: The above demonstrates that the existing Baseline Requirements already require that, for each and every certificate issued, the CA follow the appropriate verification steps for each piece of presented information. Further, as discussed during rekey discussions, this applies for all issuance - as rekey is not a form of separate issuance. Finally, we have long recognized consensus that the act of issuing a certificate uses the current version of the Baseline Requirements - that is, there is only 'one' version in force at any given time. Recognizing the challenges this may present for rekey, CAs are allowed to reuse information obtained from previous issuances, if and only if the means of obtaining that information is defined in the 'current' Section 3.2. <br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Suggestion: Remove this.</div><div class="gmail_extra"><br></div></div>