[cabfpub] Preballot - Revised Ballot 190

Ryan Sleevi sleevi at google.com
Fri May 19 05:12:26 MST 2017


On Fri, May 19, 2017 at 2:00 AM, Kirk Hall via Public <public at cabforum.org>
wrote:
>
> As Gerv said a few weeks ago, requiring revalidation of all outstanding
> domains every time there is an incremental improvement in domain validation
> methods will turn out to be a tremendous disincentive to ever adopt such
> incremental improvements.


Luckily, this is an incorrect interpretation of what's required. It would
only affect those domains affected by those changed validation methods,
only if they're changed in incompatible ways, and only when an applicant
requests a certificate.

For what it's worth, the same logical argument you're making can be applied
to CA selection - that is, the reuse of domain validation information
provides a tremendous disincentive to ever changing CAs, because it would
require revalidation of any applied-for domains. As such, the opposition
could, in some extent, be seen as a way to try to discourage market
flexibility by offering incumbents greater advantages over their
competitors.

We cannot argue that domain validation is difficult without also
acknowledging that, in part, the reuse serves to benefit incumbents and
discourage market flexibility. That is the reality of what is being
discussed.


> If there is ever a strong evidentiary showing that a particular existing
> validation method has *actually* resulted in a meaningful number of
> misissued certificates, everyone would likely agree to improving the
> validation method immediately and launching a campaign to revalidate all
> the affected domains over a short, reasonable period.


I wish this were true, but this is simply posturing. Google raised concerns
with the web based domain validation, for which we saw - and continue to
saw - 'not approved' certificates issued. CAs have responded, in turn, by
suggesting these certificates - issued against the domain holders will -
are not actually 'misissued', since they were 'properly' validated.

This was over three years ago, and we still do not see progress. It appears
that CAs are putting cost in front of security, but such as it goes with
the Baseline Requirements.


> However, in our current discussion of Ballot 190, no such strong
> evidentiary showing has ever been made by anyone, and so Ballot 190
> clarifies that the long-standing rule permitting reuse of proper validation
> data under BR 4.2.1 and EVGL 11.14.3 continues in place.
>

That is an interesting way of phrasing, as a way to dismiss the past
members-only discussions and examples raised.

To the more substantive, technical part of your argument - that is, to
ignore the logical flaws in the other aspects - it would appear you may be
misinterpretating Peter's explanation, or at least, taking a degree of
liberalness with it.

That is, there's the reuse of data and documents - 4.2.1 - and there's the
reuse of domain validation - 3.2.2.4. Peter rightfully pointed out the
arguments with 3.2.2.4 allowing this reuse, but you agreed by citing 4.2.1.

I do not think there is a reasonable argument for suggesting that the
domain validation process itself constitutes data or documents - that part
clearly contradicts with the language in 3.2. I think Peter's summary of
the debate around 3.2.2.4 is reasonable and accurate, but it's entirely
separate from 'reuse of proper validation data' - because, very clearly,
when you're using one of these legacy methods, you are _not_ reusing
previous data to verify the current request (4.2.1) - you're using a
previous validation to skip domain validation entirely (3.2.2.4).

Does that help clarify the difference for you about what's being discussed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170519/8eb375b6/attachment.html>


More information about the Public mailing list