[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 4:11 PM, Peter Bowen <pzb at amzn.com> wrote:

>
> I wasn’t asking about validation methods, I was asking about delegation of
> rights.  When a corporation appoints an officer (who can sign for the
> company, or put another way has a delegation from the corporation), it is
> persistent.  If I give someone power of attorney for financial matters, it
> isn’t only valid for bank accounts which existed at the time the PoA was
> signed.   If someone has the right to sell a domain, cancel a domain, or
> transfer a domain (all things which can be done by delegating the right to
> manage any domain with a given registrant entity), why should they not have
> the right to approve certificates for the domain?
>

I understand the appeal of the analogy, but it's not entirely apt. As
described, this is the notion of someone granting themselves PoA (and
without necessarily even having to disclose this) in perpetuity.

Fundamentally, this is a problem with an 'ownership' model of domains, as
it attempts to intentionally evade the notion of whether the Applicant
Representative is authorized. The discussions during the F2F were very
illustrative of this, and the creativity CAs apply to try to reach the
Applicant and allow the Applicant to self-attest their authorization.

Let's set aside the ownership question for a second, though, because it's
clear that how CAs have interpreted "domain ownership" is fundamentally at
odds with a basic level of security - both for users and "victim" domain
holders (even if it helps a subset of domain holders).

Consider the use of .7, in which we already permit (by virtue of CNAME) an
expression of delegation to a separate entity via DNS. 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?

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180317/22ba053d/attachment.html>