[cabf_validation] Using 3.2.2.4.2/.3 for future domains

Wed Mar 21 04:39:27 MST 2018

Delegation to the CA itself, though, can be subject to audit requirements.  That’s one of the cases I’m potentially the most concerned about.  Delegation to your service provider is something we’ve long agreed is a feature, not a bug.

There’s also the point that if domain validations are no longer fresh (which may be fine), then we might want to adjust requirements elsewhere, for example around 3.2.5 validation of authority (or elsewhere) to compensate.  I’ll post a more concrete case that I’m worried about when I have more time, because it’s easier to discuss concrete cases.  Maybe if we can solve (or not solve) a few concrete cases, it will help.

Rules around CNAME chasing and redirects outside of the authorized domain name have already been discussed in the VWG several times.  Will that just encourage people to auto-forward postmaster at example.com <mailto:postmaster at example.com>  to email-validation at digicert.com <mailto:email-validation at digicert.com> , which auto-responds?  Probably.

These are just things we have to think through.

These sorts of considerations also cause me to want to start working on restricting DCV methods via CAA again, so people can opt their domains out of having to worry about some of these things.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, March 21, 2018 11:00 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: Wayne Thayer <wthayer at mozilla.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>; Peter Bowen <pzb at amzn.com>
Subject: Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains

So long as we allow validation via email (.2, .4), via SMS (.2), via phone (.3), via fax (.2), or via postal mail (.2), then we fundamentally cannot restrict delegation. That's because every one of those methods is wholly possible to delegate in a way indistinguishable to a CA, and an agreement with the Applicant that "I have not delegated" is wholly unenforcable.

So long as allow the standard DNS, and do not specify a profile of DNS, then .7 fully permits delegation.

I'm ignoring the fact that .6, .8, .9, and .10 can equally be delegated to other entities on a permanent, undetectable fashion.

So every single one of our methods allows for a delegation of authorization, on a permanent basis, and without detectability by the Ca. If we think that this is a "good time to think about this", then we have fundamentally have to start from a blank slate if we disagree with it. So it's not worth thinking about, nor looking at them with "a critical eye and see if they do what we want", because if the answer is "no", then every single validation method has to go.

On Wed, Mar 21, 2018 at 6:37 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

Given that I said I was just thinking about this, and leaning towards *not* doing anything, and perhaps moving towards being mildly in favor of this sort of thing, what is your justification for “it sounds like you're very much in favor of ripping out all validation methods and starting over (which is what it'd take)” ?

All I said was, contrary to your assertion that this problem is unsolvable and therefore all discussion of it must cease (which I think is unreasonable), that it’s worth continuing to keep the issue in mind as we discuss improving the validation methods and thinking about the consequences.  I think that’s a pretty reasonable position.

Specifically, if we’ve decided that our assumptions have changed about what we are validating (which we haven’t nailed down well enough anyway, and probably should), we should think about what those implications are.  For example, are we being too strict with freshness of other methods if we allow these sorts of things with these methods?

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Wednesday, March 21, 2018 10:26 AM
To: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Cc: Wayne Thayer <wthayer at mozilla.com <mailto:wthayer at mozilla.com> >; CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >; Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com> >
Subject: Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains

OK. If we're willing to explore no longer using DNS or email to validate domains, then I agree, this could be a fruitful exercise. We probably won't have any technically valid way to validate domains, but sure, if we want to go down that route, ok, then it's worth thinking about.

I hope we're better focused at scoping our work, and more pragmatic in recognizing that unless we're willing to rip it all out, it's very much a moot point, but it sounds like you're very much in favor of ripping out all validation methods and starting over (which is what it'd take).

On Wed, Mar 21, 2018 at 6:22 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

Oh, it certainly is possible to meaningfully do things about it.  They just might result in validation requirements that look a lot different from today’s validation requirements.  Given that we’ve currently embarked on a process of evaluating our current validation requirements and possibly making them very different, this would seem to be a good time to think about this.

So I don’t think your argument that many of the current validation methods can be used to do this is a reasonable argument for why we can’t have a discussion about it.

-Tim

These sorts of things turn that on their head.  That may be fine, but we should look at them with a critical eye and see if they do what we want.  The answer may be yes.  I’m still thinking them through.

Right, and I'm disagreeing with that framing for how to approach it. If we're going to Have Opinions about it, we first have to explore whether it's even possible to meaningfully do anything about it. If not, it's a lot of handwringing and pearl-clasping for nothing.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180321/859bf678/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180321/859bf678/attachment-0001.p7s>