On Fri, Mar 15, 2019 at 12:31 PM Jan Schaumann via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I also think that's reasonable, since any number of services might host
> their apps on the provider's platform, so they likely have a large
> number of CNAME records pointing to them.  For each one, the service in
> question might use a different CA, and ghs.googlehosted.com (in this
> example) would need to add those CAs to its CAA records.
>

I guess I'm confused still.

It sounded like your concern was that CDN was using their own
CDN-contracted CA, in which case, adding those CAA records should be fine.
But this response makes me think you're thinking of a "bring your own cert"
scenario, in which case, lacking CAA records is exactly what's intended.

I don't think we here will really be able to do anything for this; as you
note, this is really a question about fundamental DNS specification, and
whether or not other records can live along-side a CNAME. That seems like
it'd be IETF's DNS group?

If CDN wants to restrict what CAs its customers use (e.g. because the CDN
provisions certificates),  having the CDN set CAA seems fine. If the CDN
does not want to restrict, it's not clear that having the "original" site
restrict is necessarily good or desirable? I'm just confused still about
the use case and value.
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
  • CAA records on a CNAME Jan Schaumann via dev-security-policy
    • Re: CAA records on a C... Ryan Sleevi via dev-security-policy
      • Re: CAA records on... Jan Schaumann via dev-security-policy
        • Re: CAA record... Ryan Sleevi via dev-security-policy
          • Re: CAA re... Jan Schaumann via dev-security-policy
            • Re: C... Ryan Sleevi via dev-security-policy
              • R... Jan Schaumann via dev-security-policy
                • ... Matt Palmer via dev-security-policy
                • ... Jan Schaumann via dev-security-policy
                • ... Corey Bonnell via dev-security-policy
                • ... Jan Schaumann via dev-security-policy
                • ... Hector Martin 'marcan' via dev-security-policy
                • ... Corey Bonnell via dev-security-policy
                • ... Hector Martin 'marcan' via dev-security-policy

Reply via email to