[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Dimitris Zacharopoulos]

On 16/3/2018 3:47 μμ, Ryan Sleevi wrote:
>
>
> On Fri, Mar 16, 2018 at 9:25 AM, Dimitris Zacharopoulos
> <jimmy at it.auth.gr <mailto: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?

Perhaps I understood something different. I checked all previous F2F
meeting minutes that were circulated first to the management list and
then to the public list and didn't find minutes from any working group
day. Some working groups have circulated minutes through their own
mailing list (which are accessible to the public), which is what
happened in this case.

Section 5.1 of the Bylaws specifically describe the process of Draft
minutes of Forum meetings, by sending these Draft minutes to a Member
Mail List, which is not accessible by the public. Is this your
expectation for the Working Group meetings as well? In any case, anyone
can consider what I posted as "draft minutes" and can comment/correct
any misrepresentations. I tried to be as clear as possible but there is
always room for improvement :)


>  
>
>>         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"
>>         <mailto: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"
>>         <mailto: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
>>     <mailto: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"
>     <mailto: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
> <mailto: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.

In the case of DV, I'm afraid we are now more confused by this
statement, because (from the F2F discussion), I understood that the
"Applicant Representative" is just a name (e.g. "IT Department") and :

  * an email address
  * a Phone number
  * a physical address

in the Domain Contact information.

It would greatly help if we could clarify what was discussed at the F2F
and quoted in my previous message:


--- QUOTE BEGINS ---

All information in the Registrant Information (email, phone, postal
address) is treated as "Authorized Representative". Even if the Contact
Person is "IT Center", a call to this number and a dialog like the
following should suffice for the verification and authorization.

- CA: "I need to reach the IT Center to verify a Certificate Request"
- Domain Owner: "Yes you have reached the IT Center"
- CA: "We have received a Public Key (blah blah, hash of the key) for
Domain example.com <http://example.com>. Can you confirm the request and
authorize issuance?"
- Domain Owner: "Yes"
That's all. Similar to email aliases where we don't know the exact
Natural Persons in the recipient list, the same applies to the telephone
number or if using the postal address.


This was a very critical clarification moment at the last F2F. For
Domain Validation purposes, we clarified what the "Authorized
Representative" is expected to be, for the Baseline Requirements. Does
the description in the minutes accurately represent the current
expectations of the Baseline Requirements? I think it is a fundamental
issue for this discussion to clarify these expectations.

--- QUOTE ENDS ---


Thanks,

Dimitris.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/188919e2/attachment-0001.html>