[cabfpub] Domain validation

[Jeremy Rowley]

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>
Cc: CA/Browser Forum Public Discussion List <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://cabforum.org/pipermail/public/attachments/20170516/03eca71e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170516/03eca71e/attachment-0001.bin>