[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Doug Beattie]

I’m not sure I follow the details or necessarily agree with Dimitris (sorry).  Let me propose this a different way.

First, let’s forget about method 1, that has no bearing on this proposal.

For this proposal, we’re looking at the specific validation methods in 3.2.2.4.2/.3/.4 and we’re giving the domain approver the option of saying: If you see any future domains that I (same applicant) request to be added to my managed account with the same contact email (or phone, SMS, postal address, fax) that you used to contact me for this approval, then just approve them and don’t “bother” me.

If I wanted to add a domain to my managed service account and used the email listed in who-is, I would be asked 2 questions upon receipt of that approval email:

1)      Do you approve this domain to be added to your account, and

2)      Do you approve, in advance, all domains that have this email address listed in who-is .

Assume I said yes to #2.  If I created a new domain with my email as a point of contact and I (same applicant) asked for that to be added to my managed account, the CA would verify that the email address from who-is matches, then add it to my account.  No need to send me another email (or phone call, or postcard, or fax or SMS)

For the sake of clarity, if I said yes to #2, and if the approval was done via email, future domains CANNOT be automatically added if the email does not match even if the SMS, Fax, Postal or phone match.  Remember, the scope of this is only for that applicant, same as reusing the domain validation for any domain.  You’re reusing this authorization for other domains that would be validated using exactly the same method and contact details (back to the same domain owner).

This method would support phone, fax, email, SMS and postal address methods, same as methods 3.2.2.4.2/.3/.4 do today.

I think this resolves the issues you pointed earlier:

-          The Applicant is not involved in the approval process

-          This is an explicit authorization from the domain owner or contact

-          There is no subscriber agreement issue

-          This does not involve 4.2.1

-          The Stripe related vulnerability does not exist

-          There is no confusing/vague Organizational matching logic needed

Doug


From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Validation
Sent: Friday, March 16, 2018 11:37 AM
To: Dimitris Zacharopoulos <jimmy at it.auth.gr>
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 Fri, Mar 16, 2018 at 10:51 AM, Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto: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<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'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<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 ---
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/92529df8/attachment-0001.html>