On 16/03/2019 10:25, Jan Schaumann via dev-security-policy wrote:
someapp.example.com, over which I have control is a CNAME, so I can't
set a CAA record there. Let's say the CNAME points to
ghs.googlehosted.com.
Your suggestion is to contact Google and ask them to please add a CAA
record to that domain for a CA that a third-party (to them and myself)
chooses. My experience has been that Google, Akamai, Cloudflare,
Amazon, and Microsoft etc. are not amenable to adding such records.
I think part of the problem here is that the CAA specification has no
"allow all" option. Third party hosting providers probably want to allow
their customers to use any CA they wish, so they lack CAA records.
However, there is no way to specify this once you have already
encountered a CAA record, so by the time you follow the CNAME, you're stuck.
The default CAA behavior can *only* be specified by default, by the
absence of records throughout the entire tree. In my optinion this is an
oversight in the CAA specification.
My use case is different, but somewhat related. I host services for an
event under example.com, e.g. <service>.example.com, but I also have a
dynamic user.example.com zone (several, actually) where users
automatically get a dynamic record assigned at
<hostname>.user.example.com. I use Let's Encrypt for all of the
services. Currently I have a CAA record for example.com, but this also
locks all the dynamic users into using Let's Encrypt, while I want them
to be free to use any CA. I could instead have a CAA record for <every
individual service>.example.com, but this is hard to manage and less
secure, as it would allow issuance for all nonexistent names and is
harder to manage. Ideally I would just set a CAA record for "*" on
user.example.com and that would solve the issue, but the current CAA
specification has no mechanism for this.
If CAA had a way to signal an explicit "allow all", then third party
hosting services could signal that on their overall zones in order to
solve this problem with CNAMEs (of course, customers who wish to lock
down their CAA records for such third-party hosted domains would have to
get CAA records added to them, but I think that makes more sense as an
explicit thing rather than breaking CNAMEs by default).
--
Hector Martin "marcan"
Public key: https://mrcn.st/pub
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
