Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case).
Thanks, Corey ________________________________ From: Corey Bonnell <[email protected]> Sent: Monday, March 18, 2019 16:42 To: Hector Martin 'marcan'; Jan Schaumann Cc: [email protected] Subject: Re: CAA records on a CNAME Perhaps not very elegant, but you can encode an “allow all issuers” CAA RRSet by specifying a single iodef CAA record without any issue/issuewild records in the RRSet, which will probably be treated as permission to issue for CAs. I say “probably” because the RFC wasn’t clear on the proper handling RRSets with no issue/issuewild property tags, but this was clarified in the CAB Forum in Ballot 219 (https://cabforum.org/2018/04/10/ballot-219-clarify-handling-of-caa-record-sets-with-no-issue-issuewild-property-tag/) to explicitly allow the above behavior (although of course some CAs may be more restrictive and disallow issuance in this case). Thanks, Corey ________________________________ From: dev-security-policy <[email protected]> on behalf of Hector Martin 'marcan' via dev-security-policy <[email protected]> Sent: Monday, March 18, 2019 14:26 To: Jan Schaumann Cc: [email protected] Subject: Re: CAA records on a CNAME 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmrcn.st%2Fpub&data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636884835910007451&sdata=AvRYycQp7w0zMB2to49mL0MqPdkscrDmw91ePNwKJ5k%3D&reserved=0 _______________________________________________ dev-security-policy mailing list [email protected] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy&data=02%7C01%7C%7C8c18001675284d88925f08d6ab6246d5%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636884835910017456&sdata=OGYmdLZfK8Rktf7N62tUzaJsswMiF64cQF8uGL6eekw%3D&reserved=0 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
