[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 9:25 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:
>
> I have already sent out the minutes
> <https://cabforum.org/pipermail/validation/2018-March/000752.html> for
> the Method 1 discussion that took place during the Validation Working Group
> Summit. I don't know if other note takers will do the same for other
> methods but I compiled the minutes for method 1 in order for this
> discussion to take into consideration what was discussed at the F2F during
> the Working Group day. This doesn't go through the approval process of the
> CA/B Forum regular days.
>

Could you provide me the reference to the Bylaws to support that?


> I fully agree with the statement that the _current_operator/owner of
>> Domain Y must authorize Domain Z and Domain W for a Certificate to be
>> issued, if they are owned by the same Owner. If this _current_owner has
>> established a secure communication with a CA and has authorized Mr. Foo
>> with e-mail address "certificate-authorizations at example.com"
>> <certificate-authorizations at example.com> for all Domains owned by that
>> Organization, then the CA that matched all the Registrant Information to
>> the same Domain Owner could *send Authorization e-mails to Mr. Foo (at **"certificate-authorizations at example.com"
>> <certificate-authorizations at example.com>**) for Domain Z and Domain W*.
>>
>
> This is where we disagree. You cannot presume that the previous
> authorization for certificate-authorizations at example.com for Domain Y is
> able to be extended to Domain Z or Domain W. That implicit assumption is a
> weaker security statement than an explicit authorization - least of all
> because of the trigger for domain changes.
>
>
> That sounds different to what I was trying to say. I said that the CA
> would still need to send an authorization for each new Domain (Z and W) to
> "certificate-authorizations at example.com"
> <certificate-authorizations at example.com>. For Domain Y, the Domain
> Contract information is the same as Domain Z and Domain W. They practically
> represent the same Domain Owner that ultimately signs the Subscriber
> Agreement and is bound by the Terms of Use.
>

Correct, it sounds different from what you were trying to say, because I'm
disagreeing with what you were trying to say as being acceptable :)

I'm saying you cannot and should not assume that Domain Z and W are
represented by certificate-authorizations at example.com, despite the
organizational affiliation. You cannot and should not treat it as an
implicit authorization to issue (where implicit includes a contract
agreement that covers future domains).


> The distinction here is that while you've asserted the same corporate
> identity, you haven't asserted that the Representative you determined for Y
> is also valid to be a Representative for Z or W. You can't trust the
> Representative to say "Trust me", and you can't treat the existence of the
> WHOIS information as a foregone authorization. Even if you have a letter
> saying "I authorize all future domains", that's still based on a model of
> Applicant-Attacker self-authorizing for future domains, which is a strictly
> weaker validation assurance.
>
>
> The "Applicant Representative" IS the same for all these Domains. They
> share exactly the same Domain Contact information. They are
> indistinguishable at DV level.
>
> I still can't see a threat here, but I am merely stating my point of view.
> I'm not saying that my interpretation is the correct one and yours is not.
>

I'm disagreeing with you here, because the Applicant Representative is the
natural person, not the legal person, and all you've validated is the legal
person at this point. You have not validated that the Applicant
Representative is actually authorized for that domain - that the Applicant
has designated that Applicant Representative explicitly for that domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/610c27d9/attachment.html>