[cabfpub] Domain validation

[Ryan Sleevi]

So, first and foremost, it's unclear whether you're proposing this as a
'new' Ballot 190, or 'in addition to' Ballot 190. It's unclear if you're
trying to break the problems out, or to solve the problems themselves.

I certainly am biased towards approaching this like most organizations
approach code reviews - attempt to solve the smallest possible problem,
provided it's solved comprehensively. This is why, for example, I broke out
validation and reuse into separate draft ballots - because they are
separable problems, even if closely related.

My understanding of your goals, although understandably limited here, is
that something might be suited as:

- Ballot 190 [with whatever short-term fixes were accumulated since the
passage of BRs 1.4.1]
- [Solve the language use issue - 'confirming control' vs 'validation' vs
'authenticate']. This would be as a singular ballot, and seemingly is
independent from these other issues.
- [Solve the random value language]. This too seems solely limited to
Section 2, so it doesn't seem to need to entail the other bits.
- [Solve the wildcard / subdomain issue]. This seems to be independent of
any of the other aspects, but is also tricky and subtle enough to be worth
its own discussion.
- [Solve the reuse issue]. Clearly, saving the 'contentious' for last, even
if the simple goal is to clarify the reuse. As you know, there's a broader
spectrum of issues at play here. We have the preamble in 3.2.2.4, we have
the individual restrictions per method, and we even have requirements like
those in 4.1.2, that we want to make sure are entirely self-consistent.

That's just a thought, based on the understanding of the issues. It seems
like each of these can be broken into separate ballots. They're potentially
issues, but I don't know that trying to solve them 'all in one go' would be
the best way to resolve them, considering they don't seem interdependent on
eachother (that is, reuse is not tied to wildcard validation, AFAICT), and
some may be either more subtle or thornier to sort out.

Regardless, _each_ of these would have to be reviewed in the full context
of the BRs to make sure we don't end up with any conflicts from other
sections (again, 4.1.2 is an example, as is 4.2.1 in a less-obvious manner
but still potentially conflicting), and to figure out the best way to
resolve those issues.

I'm not sure "reuse" should go in 3.2.2.4 at all, for example, but that's
something we could discuss independent of any of the other perceived issues.

On Tue, May 16, 2017 at 12:13 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> That’s fine.  How would you like it broken up? I could break it up by
> validation method or by issue statement.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Tuesday, May 16, 2017 10:06 AM
> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] Domain validation
>
>
>
>
>
>
>
> On Tue, May 16, 2017 at 11:55 AM, Jeremy Rowley <
> jeremy.rowley at digicert.com> wrote:
>
> 1) The document is presented as a ballot because I based the revisions on
> 190.  If there are discrete sub-components someone doesn’t like, I don’t
> mind breaking it up into chunks.
>
>
>
> The problem is not about 'not liking'. It's about a tremendous amount of
> text that tries to solve a whole host of issues, all at once, and without
> clear identification of the goals or related changes. This makes it
> incredibly difficult to review, and all the more likely of a Ballot 193/197
> problem being introduced. Further, the approach to creating the ballot
> creates issues like recently discovered by Ben in Ballot 198, in which the
> 'proposed text' and the 'redlined version' actually substantially differed
> from what was actually adopted (more on that for another thread).
>
>
>
> It's not that I disagree with your goals - I think you've captured some
> very useful things to do. I'm just not sure there's any reasonable hope
> that we'd be confident it was appropriately reviewed, especially in light
> of the substantive discussion re: Ballot 190 that still needs adoption, and
> because of that, makes it very hard to consider voting in favor. This is,
> for what it's worth, notably similar to some of the subordinate CA
> discussions.
>
>
>
> While that comes across negative (and almost certainly would be reflected
> in a vote, should it come to that), I'm incredibly thrilled that someone
> such as yourself has taken a comprehensive look at it, and I'm thrilled
> that you've found and identified issues. Just the means of attempting to
> fix them is perhaps less than ideal, and much like I'd send back an overly
> complex code review back to the submitter as "overly complex; simplify",
> I'm trying to figure out if there's a way to tease out the issues or look
> at incrementalist approaches here.
>
>
>
> This is why even with a 'small' change (the OCSP profile), which only
> removes a few lines of text, I tried to extensively annotate the reasonings
> behind each change, the dependencies, and their relationship - see
> https://github.com/sleevi/cabforum-docs/pull/2
>
>
>
> I'm also not sure I'd agree with some of your problem statements, so
> that's where helping identify what you see as the problem can sort out an
> appropriate solution :)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170516/551b81a1/attachment-0001.html>