[cabf_validation] FW: Using 3.2.2.4.2/.3 for future domains

[Doug Beattie]

Hope the comments come through clearly this time.  Outlook is not all that flexible…

From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Friday, March 16, 2018 2:31 PM
To: Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>; Dimitris Zacharopoulos <jimmy at it.auth.gr<mailto:jimmy at it.auth.gr>>
Subject: Re: [cabf_validation] Using 3.2.2.4.2/.3 for future domains

On Fri, Mar 16, 2018 at 2:10 PM, Doug Beattie <doug.beattie at globalsign.com<mailto:doug.beattie at globalsign.com>> wrote:

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.

Except you haven't necessarily validated that it's "same applicant".

 Re-use of vetting data for the same domain requires that this be limited to the same Applicant, so we can be sure the same rules apply here.  It must be the same Applicant for “future” domains also.

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)

Except you haven't actually validated that the Applicant controls/authorizes the additional domains, nor that they're authorized for #2.

 I don’t think Applicants have anything to do with controlling or authorizing the domains in a managed account, do they?  Let’s try to focus this on a Managed account where domains are requested, validated, enabled for use within an Enterprise account, and then later, an Applicant places a certificate request that uses one or more of the prevalidated domains in the account.

Managed Account FAQs:

1.       The Organization is the Applicant

2.       The Organization administrator can add users.

3.       Someone from within the account (I don’t consider this person an Applicant), requests a domain to be added

4.       The CA performs Domain Validation using any approved method

5.       The domain is now registered with the account

6.       Anyone with access to the account submits a Certificate Request.  The Organization is the Applicant

7.       Since the domains are pre-approved within that account, the certificate is issued with no additional domain validation


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
This doesn't resolve the fact that you haven't actually established that the Applicant authorized for those additional domains. You're trusting the Applicant-Attacker, without actually establishing the binding.

Consider the following:
I work at Victim Corp as network administrator, and request a certificate for example.com<http://example.com> from GlobalSign. I set the DNS Hostmaster email to hostmaster at example.com<mailto:hostmaster at example.com> , which forwards to my mailbox, and I request your proposed future-authorization for all new domains. I create an account with GlobalSign, using my sleevi at example.com<mailto:sleevi at example.com> email, to manage these requests.

 Ok, so at this point you have an account for Victim Corp at GlobalSign and you are a legitimate Applicant/Subscriber for this company with login credentials.  As a network administrator you’ve set up forwarding from hostmaster at example.com<mailto:hostmaster at example.com> to sleevi at example.com<mailto:sleevi at example.com> so you can approve example.com via an email sent to sleevi at example.com<mailto:sleevi at example.com>.
Then I (leave the company, transfer to a different role). Victim Corp decides to no longer use GlobalSign, and goes over to HARICA (if, well, HARICA issued commercially). My successor doesn't know about my account / thinks the relationship with GlobalSign is over. They introduce new domains, such as example.net<http://example.net> and example.org<http://example.org> for Sales and Marketing, respectively, with the same "hostmaster at example.com<mailto:hostmaster at example.com>" email. Yet I, ex-employee/ex-authorized party, can now cause certificates for example.net<http://example.net> and example.org<http://example.org> to be issued, even though I have no legitimate authorization to do so.

 There are 2 things here:

1) As an ex-employee, can you authorize certificates for example.net because Victim Corp left the forwarding in place?  If so, then you could continue to get certificates for example.com from any CA.   I don’t see how this proposal causes this problem.  Victim Corp needs to fix whatever tricks Sleevi put in place when he leaves.

2) If your company does not terminate the account at GlobalSign, or your access to the account, when they decide to no longer use GlobalSign, that’s a real problem for their lack of attention. If this account remains and you remain with access to place orders from within the account, then it’s Victim Corp’s problem. You’d be able to continue issuing certificates for example.com and any other domain that has been previously registered regardless of this discussion about validation of future domains.  Did I misinterpret your comments above?

Remember, new requests that come in after you leave must be made from within the authenticated Victim Corp account at GlobalSign since the requests must be from the same Subscriber/Applicant, “Victim Corp”.  You would not be able to place a “retail” order for the domain and receive a certificate without receiving and acting on the approver email since GlobalSign would have no way to match the applicant from this order back to your or the Victim Corp account.
This is why it's essential to ensure that the domain operator be contacted. I don't think a "Well, don't do that" is a sufficient answer to the problem, because this is the inherent risk of scoping future authorizations without revalidation. I understand that some CAs even want this grant to be perpetual (i.e. not tied to an expiration, such as the 825 days from when the contract was executed), which is an even worse result.
This discussion doesn’t have anything to do with when contracts were executed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/637223a3/attachment-0001.html>