[cabf_validation] Using 3.2.2.4.2/.3 for future domains

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 2:10 PM, Doug Beattie <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".


> 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.


> 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 from GlobalSign. I set the DNS Hostmaster email to
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 email, to manage these requests.

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 and example.org for Sales and Marketing,
respectively, with the same "hostmaster at example.com" email. Yet I,
ex-employee/ex-authorized party, can now cause certificates for example.net
and example.org to be issued, even though I have no legitimate
authorization to do so.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180316/d5327c75/attachment-0001.html>