[cabfpub] Ballot 194 – Effective Date of Ballot 193 Provisions

[Ryan Sleevi]

Google votes NO.

Our reasoning for opposing this ballot is two-fold:

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.

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.

This approach, which has been discussed in the past (c.f. Scottsdale,
Meeting 37,
https://cabforum.org/2016/02/17/2016-02-17-minutes-of-f2f-meeting-37/#Compliance-Assessment-Coordination-with-auditors-and-browsers
), 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.

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170416/ddd80768/attachment-0003.html>