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

[Ryan Sleevi]

On Fri, Mar 16, 2018 at 3:53 PM, Doug Beattie <doug.beattie at globalsign.com>
wrote:

>
>
> Hope the comments come through clearly this time.  Outlook is not all that
> flexible…
>
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
>
The BRs consider this the Applicant (or Applicant Representative,
depending). I don't know what you call it, but if it's anything but those,
you're wrong.


> 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
>
And the person who submitted is the Applicant Representative.

> 7.       Since the domains are pre-approved within that account, the
> certificate is issued with no additional domain validation
>
I'm not sure your notion of "Managed Account", but it's not a BR-defined
term. If you believe what you described is valid under the BRs, it would be
useful to describe it as the BRs do, so that we can clearly communicate.


>
>
>
>
> 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.
>
>
>
>  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 to sleevi at example.com so you can approve
> example.com via an email sent to 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 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.
>
>
>
>  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?
>

No. The forwarding is gone.


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

Yes, see above. But fundamentally, I find it unacceptable for CAs to foist
their desire for convenience to a security risk for users. This is the same
reason why we're discussing things like TLS-ALPN in the context of .9 and
.10 - because as attractive as it may be for some CAs to ease issuance, the
security risks they outsource to the ecosystem are unacceptable.


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

No. Your description may be what you declare to do, but it's not what's
actually been proposed here. And even if it was, it still highlights the
risk that in order for Victim Corp to know, they must retain and revoke all
credentials - and in your example described above, it may have been a
dedicated account.

That's an unacceptable, undiscoverable risk to the ecosystem, especially in
a model of hostile termination. There's no way to recover from that short
of contacting every CA - and every reseller - to revoke that.


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

It absolutely does, because a contract without expiration has all the same
problems as certificates that are validated based on the random number in
the serial of a certificate to avoid having to check authorization.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180317/ea81b8b1/attachment-0001.html>