[cabfpub] Domain validation

[Kirk Hall]

Jeremy, was this ballot discussed in the Validation Working Group?

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley via Public
Sent: Tuesday, May 16, 2017 12:39 PM
To: Ryan Sleevi <sleevi at google.com>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: [EXTERNAL]Re: [cabfpub] Domain validation

The original proposal actually utilized those sections and required checking WHOIS for changes within 90 days of issuance. I did want to discuss that during this process, but we can table that for the reuse portion.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, May 16, 2017 10:36 AM
To: Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>
Subject: Re: [cabfpub] Domain validation



On Tue, May 16, 2017 at 12:25 PM, Ryan Sleevi <sleevi at google.com<mailto:sleevi at google.com>> wrote:
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.

Oh, and one last piece of advice I offer when reviewing code :)

- Don't restructure your code for 'future feature X' until you know what the shape of 'future feature X' will look like. To me, that means avoid restructuring reuse 'so we can reduce it later' - unless/until we're ready to reduce the reuse period :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170516/15de63f1/attachment-0003.html>