[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 10:51 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr>
wrote:

>
>
> 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>
> 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'm surprised to hear a difference, if only because minutes trigger IP, and
also represent positions, hence the desire for them to be correct.

5.2(b) establishes WG minutes will be published, but 5.1(a) discusses draft
minutes. Hopefully governance reform ensures this is clear and unambiguous.


> 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. 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 ---
>
You stated "Applicant Representative" earlier. Applicant Representative is
a defined term:

Applicant Representative: A natural person or human sponsor who is either
the Applicant, employed by
the Applicant, or an authorized agent who has express authority to
represent the Applicant: (i) who signs and
submits, or approves a certificate request on behalf of the Applicant,
and/or (ii) who signs and submits a
Subscriber Agreement on behalf of the Applicant, and/or (iii) who
acknowledges the Terms of Use on behalf
of the Applicant when the Applicant is an Affiliate of the CA or is the CA.


I'll review the minutes in full, but likely not until next week, but I do
disagree with the introduction of "Authorized Representative" as a concept
and think that misses much of the nuance to the past conversation and
introduces sufficient confusion that it's probably a bad framing.

In the context of .2 and .3, we discussed contacting *the named entity*.
That is, if the Domain says "Bruce Wayne" then we need to reach Bruce
Wayne, the CA can't say "Bruce Wayne or his loyal associate Dick Grayson" -
because that's not the named entity in the domain. This was in the context
of phone calls, to ensure we reach the correct party. You can't, for
example, ask for "The IT Department" if the domain says "Hostmaster" as the
contact.

For email addresses, this is not an issue. Email aliases are not at all
special here, because you have a defined mailbox.

The problem is that this doesn't work with .1, as it existed or as it's
proposed to exist - with all of the mitigations we've discussed. That's
because you're back to dealing with an abstract notion - you're
fundamentally asserting a desire to be able to call the central number or
'corporate office' to get the assertion necessary. That's the first problem
- .1 is strictly weaker than .2, .3, or .4 for precisely the reasons we
discussed in those subsequent methods - this is *just* for validating
Domain Y.

Imagine you're validating Domain Y, and you've validated that "Bruce Wayne"
is authorized to speak for that domain - and possibly having delegated to
his boy "Dick Grayson." The argument being made here is that since you
validated "Bruce Wayne" delegated to "Dick Grayson" for Domain Y, we can
also assume that
1) "Bruce Wayne" is authorized for Domain W and Domain Z
2) Because "Bruce Wayne" is authorized, then so too must "Dick Grayson" be
authorized.

But that's not correct - it may be that "Alfred Pennyworth" is responsible
for Domain W (either as expressed in WHOIS or as expressed by the
organization) - so you can't be sure until you've exercised the .2/.3/.4
validation. It may be that "Bruce Wayne" delegated to "Clark Kent".
Similarly, you also can't assume that any future domain that says
"Superfriends, Inc" means that both "Bruce Wayne" and "Clark Kent" are
equally authorized.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/e1c34516/attachment.html>