On Thu, Oct 10, 2019 at 11:42 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Question, is there any prohibition against demonstration of domain control
> being delegated to a third party or even the CA itself? I don't think so,
> but figured we've discussed differences in interpretation a lot lately so
> wanted to see if people agreed.
>
Huge thanks for bringing this up early :) Definitely the example for all
CAs :)
That said, you probably could have worded better, "demonstration of domain
control being delegated to a third party" is... probably not the best way
of framing ;)
> I mean, the obvious issue is the customer.com domain would need to want
> to delegate this domain.com. But if you had a pretty non-technical person
> operating the DNS, they could set it to the domain.com name and leave
> their DNS settings forever.
>
> This looks allowed under the BRs, but should it be? Or is it like key
> escrow - okay if a reseller does it (but frowned upon). Totally not cool if
> the CA does it.
>
This is definitely a good way of looking at it!
I'm familiar with at least one CA using an approach like this - Amazon
Trust Services, with
https://docs.aws.amazon.com/acm/latest/userguide/gs-acm-validate-dns.html .
There's subtlety here, though, which is why I like how you drew the
comparison to key escrow.
On first glance, it seems Amazon Trust Services is issuing certificates to
Amazon Web Services, both (through a complex structure) Affiliates, on
behalf of the user. And so it might seem that the user is pointing their
DNS to the CA, and that's how it's working.
However, when you look through the CCADB disclosures, along with the
certificates actually issued, it's clearer that the user is pointing those
records to Amazon Web Services, but the actual issuing CA is DigiCert (as
disclosed at https://www.amazontrust.com/repository/ ). It's also the case
that, if you look at how things are setup, the domain holder isn't the one
applying for the certificate - it's Amazon Web Services applying for the
certificate (i.e. they are the Applicant, not the domain owner), and AWS
configuring their own DNS records to contain a random value, to demonstrate
to the CA (DigiCert) that AWS, the Applicant, is authorized for the domain.
It's a really elegant solution, but it turns out it's not a "CA
self-dealing" kind of thing, which would have been useful as an example if
it was already allowed.
Now let's discuss how this idea could all go wrong, because it teases out a
little why the question of who is Applicant is relevant and important to
understanding.
Let's imagine that I setup the following (and I'm going to butcher this
pseudo-code, so bear with me)
_validation.sleevi.example 3600 IN CNAME .ca.example
.ca.example 1 IN CNAME .random.ca.example
.random.ca.example 1 IN TXT "{the CA challenge goes here}"
Now, whenever the CA receives a request to validate "sleevi.example", they
map that to a domain-id. They then update the CNAME, and the TXT record, to
match the CA-defined challenge value. Then, they issue a TXT record lookup
for _validation.sleevi.example, get the challenge value back, and huzzah,
the cert is authorized!
But there's a small problem with this. Who was the Applicant requesting
sleevi.example? From the CA's perspective, how does it distinguish me, the
legit domain holder, from 'evil hacker'? In the Amazon case, AWS is the
Applicant, and AWS is the one doing this fancy DNS stuff, so it's clear -
only AWS can do this, and they're who the user delegated to.
However, if the "party doing this domain dance" is != "the applicant", then
a lot can go wrong here, because they might do the dance for two different
applicants. The easiest example would be if the CA, for every CSR it
received, regardless of the Applicant, it updated the for
sleevi.example - at that point, anyone in the world could get a cert for my
domain from that CA, and that would not be the good result.
This would suggest that we don't want the CA doing it, because the CA is
not the Applicant, and the goal of 3.2.2.4 is to make sure the Applicant
can demonstrate control.
Another way of looking at this is imagining the following?
- Do we think it's allowed by the BRs for the domain operator to set their
MX to be the CA, so the CA can auto-answer their own emails sent under
3.2.2.4.4.?
- Do we think it's allowed by the BRs for the domain operator to give the
CA FTP/SSH/file upload access to /.well-known/pki-validation, so that the
CA can place the answer file on the server, and then request it as the CA,
under 3.2.2.4.6?
- Do we think it's allowed by the BRs for the domain owner to set an email
of domain-id@ca.example using 3.2.2.4.13 / 3.2.2.4.14, and allowing the CA
to self-acknowledge that e-mail?
I seem to recall that there is a provision in the BRs that would prohibit
this, at least in that none of the above (in the CA-controlled example) are
demonstrating the Applicant themselves has control.
