<div dir="ltr"><div class="gmail_extra">Google votes NO.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Our reasoning for opposing this ballot is two-fold:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) The adoption of Section 2, as presented in the Ballot, inappropriately suggests that it is possible to ex post facto modify the expectations and to indemnify CAs. The Baseline Requirements represent a statement and guidance about the present operations of a CA for a single moment in time - at any point in time, a CA is either abiding by the BRs or it is not. At the time of issuance, a certificate was either issued consistent with the BRs or not. In matters where the BRs are unintentionally or unnecessarily restrictive, and are later modified, the matter remains that at the time prior to that resolution, the CA was in non-compliance. The impact of this non-compliance minimally is to require transparency about this matter, as evidenced with an audit qualification attesting to the fact that, during a portion of the period of time under audit, the CA did not comply with the current version of the Baseline Requirements. This is true even if there are not specific audit criteria developed for this matter, and is derived from the requirement and attestation of compliance found within Section 2.2 of the Baseline Requirements.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Despite this non-compliance, it is up to Browser Programs to determine the effect relative to their root program goals. It is undoubtedly likely that if there was consensus that a requirement was unnecessarily restrictive or prescriptive, and resulted in a qualification, the Browser Program would allow such a qualification to be overlooked, provided that the matter of non-compliance was scoped solely to that issue and no other, unrelated issues.</div><div class="gmail_extra"><br></div><div class="gmail_extra">This approach, which has been discussed in the past (c.f. Scottsdale, Meeting 37, <a href="https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Compliance-Assessment-Coordination-with-auditors-and-browsers">https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Compliance-Assessment-Coordination-with-auditors-and-browsers</a> ), represents a consistency with both the letter and intent of the BRs. As worded, Section 2 directly conflicts with that, and regardless of any other concerns with this ballot, is reasonable grounds to oppose the adoption of this ballot.</div><div class="gmail_extra"><br></div><div class="gmail_extra">2) Although presented as a final ballot (with endorsers) that immediately entered the discussion phase, Google continued to work to understand the concerns and objectives of CAs related to this matter, to ensure we had a proper understanding of the implications and impact of this requirement. While our goal is to see a reduction in the use of 'stale' data to a period more akin to one week to one month, we understand that may present unanticipated difficulties, and thus have continued to strive to understand CAs concerns (c.f. the discussions related to Ballot 196 and Ballot 190). We have withheld voting until the last possible moment, to allow for any information to be shared by member CAs that might help us understand the concerns, restricted to what is permitted in the Baseline Requirements, versus what CAs may be practicing and which may not be permitted by the letter of the BRs. Regrettably, no further information has been shared that would identify to us why CAs believe there is a greater difficulty. At its worst possible case, the adoption of Ballot 193 means that, for a period of time, CAs must treat certificate requests as if they were from new customers, if the CA had not validated the information within the past two years. This does not seem an unreasonable request, and given that it significantly improves the security of the ecosystem to ensure that certificates issued are accurate and that the information they attest is current, we support the wording of Ballot 193 as is.</div><div class="gmail_extra"><br></div><div class="gmail_extra">We are concerned with the trend by some members in the Forum to support using stale data obtained via insecure and inadequate means, methods which have been shown to have lead to misissuance, and thus our opposition to this Ballot 194 is consistent with our desire and goal to see the Web PKI's effective security substantially improve. Adoption of technologies such as CAA are stymied by the reuse of stale, outdated information, and thus actively hinder user security. As this Ballot prolongs such reuse, this Ballot thus actively hinders and harms user security.</div></div>