[cabf_validation] Using 3.2.2.4.2/.3 for future domains

Tue Mar 20 14:37:32 MST 2018

On Tue, Mar 20, 2018 at 5:26 PM, Tim Hollebeek <tim.hollebeek at digicert.com>
wrote:

> I’m moving in that direction as well.  My main concerns were, and some
> extent continue to be, what happens when the domain ownership changes, and
> some or all of the original infrastructure for continuous issuance remains
> in place, likely without the new owner’s knowledge or consent, unless they
> are super sophisticated.
>

>
> That’s basically the concern and motivation for re-validation each time as
> we discussed years ago, e.g. in Baden IIRC.  I don’t think any of the
> concerns are insurmountable, but I’d like us to think through them
> carefully in order to avoid surprises.
>

I'm not sure I understand this part.

What you describe is more an inherent risk of reuse of stale data. That is,
if the domain ownership changes, and the (old) Subscriber violates their
Subscriber agreement and fails to notify the CA, the CA can continue
issuance. And I see that being extremely likely - I'd be curious if any CA
ever sued a Subscriber for violating their Subscriber Agreement on that
dimension, or ever did anything other than "revoke" the cert.

I'd be thrilled to see the lifetime of DNS reduced to something short -
say, 3-7 days - and separately deal with OV/EV information. The reality is
we have a number of methods that make this fairly reasonable, even for the
least technically competent subscriber.

In the case of DNS ownership changes, the new owner would have to actively
maintain the record set (or email redirection), and that doesn't seem to
fit with your threat model, or at least, how I understood it.

>
>
> If it’s something we want to allow, I think we want to articulate a clear
> set of principles that can be applied across all of the validation methods
> where this sort of thing is possible, instead of working piecemeal on each
> one.  The mistake we made last time, I think, was not working from a common
> set of general principles when writing and evaluating each validation
> method.
>
>
>
> -Tim
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Tuesday, March 20, 2018 9:18 PM
> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum
> Validation WG List <validation at cabforum.org>
> *Cc:* Peter Bowen <pzb at amzn.com>; Wayne Thayer <wthayer at mozilla.com>
>
> *Subject:* Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains
>
>
>
> Can you explain why, and how you see that as different than
>
>
>
> 1) Redirecting a WHOIS email to the CA (under .2/.3)
>
> 2) Redirecting one of the 5 blessed emails (under .4)
>
> 3) HTTP redirecting (under .6)
>
>
>
> ?
>
>
>
> While I initially shared some concern with .7, the reality is that it is
> fully possible within the methods we have, while also ensuring that the
> domain operator remains in total control.
>
>
>
> On Tue, Mar 20, 2018 at 3:43 PM, Tim Hollebeek via Validation <
> validation at cabforum.org> wrote:
>
> The particular case where the CA is conducting a challenge-response
> validation with itself is the particular subset of the .7 trick that I find
> most concerning.
>
>
>
> -Tim
>
>
>
> *From:* Validation [mailto:validation-bounces at cabforum.org] *On Behalf Of
> *Peter Bowen via Validation
> *Sent:* Tuesday, March 20, 2018 1:26 AM
> *To:* Wayne Thayer <wthayer at mozilla.com>
> *Cc:* CA/Browser Forum Validation WG List <validation at cabforum.org>
> *Subject:* Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains
>
>
>
>
>
>
>
> On Mar 19, 2018, at 4:44 PM, Wayne Thayer <wthayer at mozilla.com> wrote:
>
>
>
> On Mon, Mar 19, 2018 at 9:16 AM, Peter Bowen via Validation <
> validation at cabforum.org> wrote:
>
> On Mar 17, 2018, at 7:43 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
>
>
> Consider the use of .7, in which we already permit (by virtue of CNAME) an
> expression of delegation to a separate entity via DNS.
>
> From my understanding of the problem, this may be a solution that works
> for everyone. Is it correct that under the existing .7, a CA could instruct
> their customer to create a DNS CNAME in the 'example.com
> <https://clicktime.symantec.com/a/1/ZryT-YwLkd2yiWPKFdzAn736iqkEJqPqcVkq82Qw_tQ=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fexample.com%2F>'
> zone for '_www' that points to a DNS record controlled by the CA (e.g. '
> account1234.validation.megaca.com
> <https://clicktime.symantec.com/a/1/ubwl-zQbpRDbgf5L_xWzXcVxvCSL31j-FftOSBhirXs=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Faccount1234.validation.megaca.com%2F>'),
> then perform .7 domain validation in perpetuity for 'www.example.com
> <https://clicktime.symantec.com/a/1/7Hsj_zWBQ10y2B8qv9x4qxEVTpWC9V3wHVq5tLnzwL8=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fwww.example.com%2F>'
> without any interaction from the DN Registrant?
>
>
>
> I think that would be allowed, but haven’t thought through all the
> implications of it being the CA itself.  I’ve only seen it used with CDNs
> and other delegation.
>
>
>
> If the entire concern is that the respondant in WHOIS is not the PKI
> approver (preventing .2 and .3), and that the domain operator "for reasons"
> cannot configure one of the mailboxes (.4), would the expression of a
> domain record that allowed for a designated approver suffice? This could be
> established for all new/additional domains, can be verified technically,
> can be checked, and is "no worse" than setting a mailbox under .2/.4 or a
> CNAME under .7 to delegate to a PKI approver. Does this meet the needs?
>
>
>
> My example above doesn't work for the Base Domain, so this makes sense.
> What would this special domain record contain?
>
>
>
> Your example above does work for a registered domain.  For example, given
> two records:
>
>
>
> _pki-validation.example.com
> <https://clicktime.symantec.com/a/1/2OZ8m_Ajo3_-o5yJ8DIPUstNVQkpJP-PA8CEvOavOWw=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fpki-validation.example.com>.
> IN CNAME a852f14a-1bb5-4ab4-9050-7929605844ee.
> domainvalidation.acmecorpcdn.com
> <https://clicktime.symantec.com/a/1/fxoWHK8p6PnUvmbhkP0QSwsrA8AZ7O-QHOCXIUU__G8=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fa852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com>
> .
>
>
>
> a852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com
> <https://clicktime.symantec.com/a/1/fxoWHK8p6PnUvmbhkP0QSwsrA8AZ7O-QHOCXIUU__G8=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fa852f14a-1bb5-4ab4-9050-7929605844ee.domainvalidation.acmecorpcdn.com>.
> IN TXT 9b3d28ae4a6a4410bab518acc6cbbe21
>
>
>
> That could be used to validate the whole example.com
> <https://clicktime.symantec.com/a/1/3M_K30nZEj2kAS3Vf0q-k0eFsN5sPQ9BAAp-WE7wmxY=?d=gPsBUFF9OhSf2IesWt0IDKL4D3j6P7oFASOn6759cflFSbSIX3tPOT_q2vxmgH-ehbuV13v3aUC_96YWknXy9guKVsBxaI3dW_4dlaK1VV-Sr1g3865V03RlNmejZVjK7BfAvOrRPfrpH61_CYmvnsVe1aUtnVi_rln5QpYBSfHxOsmphWdb4vwUric7RroYdJDExmVttZQXZifhqZYoNxmvksBLuD3uaoh619oS7KPFH0W7XoEA22FasbZKP_Sf7kymw6wauJvPCTZIi9e3IfDZEK3Hgj4zVIJZEzhP4ds4QEPM2nhEZBkPMqRjAMRA9SbGtwmMHtBesLxLHKRcXXZSbzA97L4pwdqoO0VmAofSk2atr6u5Os5cq9mZWAa2lVQG3ndQcdukJ0nnllkNk-impr1L6ThwhhrHlW8dJpX3&u=http%3A%2F%2Fexample.com> namespace.
> The characters between “_” and “.” can be any valid DNS label and do not
> matter.
>
>
>
> Or consider during the F2F, there was a discussion of expanding .12 in a
> way that the DNS Owner could put in a "challenge token" (of sorts) into
> WHOIS, which allowed them to uniquely and unambiguously link back to the
> notion of a CA account. Would such a link - in which the CA validated the
> existence (under the proposed ".13" rules, to be fleshed out) of this
> random token - suitably replace the need to do an organization-identity
> link? I think so.
>
>
>
> However, if the proposal of the .1 supporters is that they should not have
> to consult DNS to verify an explicit authorization to delegate - such as a
> DNS record or (additional) WHOIS configuration - and instead rely on the
> mere existence of information that ICANN requires of domain holders - then
> that will remain unacceptable, as it's a fundamentally weak proposition.
>
> I agree that an explicit authorization (similar to the approach proposed
> to "fix" .9 and .10) is much better, and I also question how useful an
> implicit but unambiguous WHOIS record match is outside of specific ccTLDs
> like the .no example we keep tossing around.
>
>
>
> These are both things worth introducing to the BRs and seeing if they meet
> needs.
>
>
>
> If my understanding of the proposal above is in the ballpark, then the
> combination of these two with the new .12 seem to cover most of what was
> lost with #1. What do CAs who've been using .1 think?
>
>
>
> We should be biased towards including more validation methods in the BRs
> if they meet the bar for security, rather than trying to limit the number
> of options.  The BRs are very different from IETF RFCs as they are
> mandatory and validation methods are a closed set, so we cannot reasonably
> say “at least two independent interoperable implementations” as we likely
> won’t even have the first implementation of a method until well after a
> method is approved.
>
>
>
> I put text forward for the .13 method in another email.  I hope that we
> can get it to a ballot soon so we can start to try it i the real world.  I
> also think DNS discovery of delegation of approval that you propose seems
> like a good path; it has the potential to allow delegation via multiple
> protocols via URI, which could offer a number of opportunities to improve
> the system.
>
>
>
> Thanks,
>
> Peter
>
>
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180320/f24796d7/attachment-0001.html>