<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 25, 2017, at 4:57 PM, Ryan Sleevi <<a href="mailto:sleevi@google.com" class="">sleevi@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Sat, Feb 25, 2017 at 4:24 PM, Peter Bowen via Public <span dir="ltr" class=""><<a href="mailto:public@cabforum.org" target="_blank" class="">public@cabforum.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">I think that the DNAME checks are unnecessary, as 6672 (and other earlier RFCs) say that the name server synthesizes CNAME records based on the DNAME record. That would leave:</div><div class=""><br class=""><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">Q(<a href="http://beta.shop.example.com/" rel="noreferrer" target="_blank" class="">beta.shop.example.com</a>, CAA) = <no answers><br class=""></span><span class="">Q(<a href="http://shop.example.com/" rel="noreferrer" target="_blank" class="">shop.example.com</a>, CAA) = CNAME, <a href="http://xmpl.cdn.bighost.com/" rel="noreferrer" target="_blank" class="">xmpl.cdn.bighost.com</a>.<br class="">Q(<a href="http://xmpl.cdn.bighost.com/" rel="noreferrer" target="_blank" class="">xmpl.cdn.bighost.com</a>, CAA) = CNAME, <a href="http://xmpl.cdnhost.xyz/" rel="noreferrer" target="_blank" class="">xmpl.cdnhost.xyz</a>.<br class="">Q(<a href="http://xmpl.cdnhost.xyz/" rel="noreferrer" target="_blank" class="">xmpl.cdnhost.xyz</a>, CAA) = <no answers><br class=""></span><span class="">Q(<a href="http://cdnhost.xyz/" rel="noreferrer" target="_blank" class="">cdnhost.xyz</a>, CAA) = <no answers><br class=""></span><span class="">Q(xyz, CAA) = <no answers><br class=""></span><span class="">Q(<a href="http://cdn.bighost.com/" rel="noreferrer" target="_blank" class="">cdn.bighost.com</a>, CAA) = <no answers><br class=""></span><span class="">Q(<a href="http://bighost.com/" rel="noreferrer" target="_blank" class="">bighost.com</a>, CAA) = <no answers><br class=""></span><span class="">Q(com, CAA) = <no answers><br class=""></span><span class="">Q(<a href="http://example.com/" rel="noreferrer" target="_blank" class="">example.com</a>, CAA) = <no answers><br class=""></span># Not doing Q(com, CAA) as we already did it; if it was <a href="http://example.net/" rel="noreferrer" target="_blank" class="">example.net</a>, we would do Q(net, CAA) here<span class=""><br class="">Result: no CAA record found<br class=""></span></blockquote></div></div></div></blockquote><br class=""></div><div class="">I think this still will have unexpected results.</div><div class=""><br class=""></div><div class="">See this real world example:</div><div class=""><br class=""></div><div class=""><div class="">;; QUESTION SECTION:</div><div class="">;; <a href="http://www.paypal.com/" target="_blank" class="">www.paypal.com</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>A</div><div class=""><br class=""></div><div class="">;; ANSWER SECTION:</div><div class=""><a href="http://www.paypal.com/" target="_blank" class="">www.paypal.com</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>453<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>CNAME<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span><a href="http://www.paypal.com.akadns.net/" target="_blank" class="">www.paypal.com.akadns.net</a>.</div><div class=""><a href="http://www.paypal.com.akadns.net/" target="_blank" class="">www.paypal.com.akadns.net</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>30<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>CNAME<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span><a href="http://ppdirect.paypal.com.akadns.net/" target="_blank" class="">ppdirect.paypal.com.akadns.net</a><wbr class="">.</div><div class=""><a href="http://ppdirect.paypal.com.akadns.net/" target="_blank" class="">ppdirect.paypal.com.akadns.net</a><wbr class="">.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>180<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>CNAME<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span><a href="http://wlb.paypal.com.akadns.net/" target="_blank" class="">wlb.paypal.com.akadns.net</a>.</div><div class=""><a href="http://wlb.paypal.com.akadns.net/" target="_blank" class="">wlb.paypal.com.akadns.net</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>30<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>CNAME<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span><a href="http://www.paypal.com.edgekey.net/" target="_blank" class="">www.paypal.com.edgekey.net</a>.</div><div class=""><a href="http://www.paypal.com.edgekey.net/" target="_blank" class="">www.paypal.com.edgekey.net</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>0<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>CNAME<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span><a href="http://e3694.a.akamaiedge.net/" target="_blank" class="">e3694.a.akamaiedge.net</a>.</div><div class=""><a href="http://e3694.a.akamaiedge.net/" target="_blank" class="">e3694.a.akamaiedge.net</a>.<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>20<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>IN<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>A<span class="m_-115641559788771776Apple-tab-span" style="white-space:pre-wrap"> </span>23.13.156.181</div></div><div class=""><br class=""></div><div class="">If <a href="http://paypal.com/" target="_blank" class="">paypal.com</a> sets a CAA record to <a href="http://symantec.com/" target="_blank" class="">symantec.com</a>, but <a href="http://edgekey.net/" target="_blank" class="">edgekey.net</a> has a CAA record to <a href="http://megaca.xyz/" target="_blank" class="">megaca.xyz</a>, then the result is that Symantec cannot issue for <a href="http://www.paypal.com/" target="_blank" class="">www.paypal.com</a> but MegaCA can (and only MegaCA can). I don’t think that this is the logical result.</div><div class=""><br class=""></div><div class="">While I do support CAA, I think we need to fix/clarify the handling of CNAMEs before mandating CAs follow CAA directives.</div></div></blockquote><div class=""><br class=""></div><div class="">Hi Peter,</div><div class=""><br class=""></div><div class="">Can you explain why you don't believe this is the logical result? I think there's a perfectly logical argument that it is the desired result.</div><div class=""><br class=""></div><div class="">Considering <a href="http://example.com/" class="">example.com</a>, which might set a CAA record to <a href="http://symantec.com/" class="">symantec.com</a>. This is because the <a href="http://example.com/" class="">example.com</a> operator knows that all of the certificates they will obtain/purchase/etc will be from Symantec. Now imagine there's a subdomain - <a href="http://shop.example.com/" class="">shop.example.com</a> . This domain is part of the <a href="http://example.com/" class="">example.com</a> hierarchy, certainly, but it's in fact operated by "Shop Corp", a turnkey shopping portal that provides custom shopping portals for tens of thousands of sites. Shop Corp takes care of everything - hosting to payment processing to shipping - all with <a href="http://example.com/" class="">example.com</a>'s branding.</div><div class=""><br class=""></div><div class="">A key point of this being that <a href="http://shop.example.com/" class="">shop.example.com</a> is not operated by the <a href="http://example.com/" class="">example.com</a> operator, but instead CNAMEs over to shop.example.com.shopcorp.example, perhaps with as many hops as you've pointed out.</div><div class=""><br class=""></div><div class="">shopcorp.example buys all of their certificates from MegaCA; in fact, they might exclusively use OV or EV certs so that "Example Corp" prominently shows when shopping <a href="http://shop.example.com/" class="">shop.example.com</a>. So shopcorp.example has a CAA record of saying MegaCA.</div><div class=""><br class=""></div><div class="">The logical consequence of this means that Symantec cannot issue for <a href="http://shop.example.com/" class="">shop.example.com</a>, only MegaCA can. But that's exactly what is intended and logical.</div></div></div></div>
</div></blockquote><br class=""></div><div>Consider Public Key Pinning for HTTP. If <a href="http://example.com" class="">example.com</a> sets a pin with “includeSubdomains”, then it applies to <a href="http://shop.example.com" class="">shop.example.com</a>. If shopcorp.example set a pin with includeSubdomains it does not apply to <a href="http://shop.example.com" class="">shop.example.com</a>. If <a href="http://example.com" class="">example.com</a> is pinning a CA key, they probably want to have a matching CAA record to help avoid confusion — they want the cert request rejected if they know resulting certificate isn’t going to work.</div><div><br class=""></div><div>I agree that your example could make sense, but it makes no sense in the common CDN case, as the CDN is just doing byte serving. The CDN probably does TLS decryption, but it might not; it would be very possible that the “CDN” is really just a better network that gets the encrypted packets to the origin server faster than would happen via the public internet. For example, you could be using Google Cloud Load Balancing in TCP mode. In this case there is zero reason for the CDN’s domain setting to control certificate issuance.</div><div><br class=""></div><div>Thanks,</div><div>Peter</div><br class=""></body></html>