[cabfpub] Ballot 187 - Make CAA Checking Mandatory

[Ryan Sleevi]

On Sat, Feb 25, 2017 at 4:24 PM, Peter Bowen via Public <public at cabforum.org
> wrote:
>
> 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:
>
> Q(beta.shop.example.com, CAA) = <no answers>
>> Q(shop.example.com, CAA) = CNAME, xmpl.cdn.bighost.com.
>> Q(xmpl.cdn.bighost.com, CAA) = CNAME, xmpl.cdnhost.xyz.
>> Q(xmpl.cdnhost.xyz, CAA) = <no answers>
>> Q(cdnhost.xyz, CAA) = <no answers>
>> Q(xyz, CAA) = <no answers>
>> Q(cdn.bighost.com, CAA) = <no answers>
>> Q(bighost.com, CAA) = <no answers>
>> Q(com, CAA) = <no answers>
>> Q(example.com, CAA) = <no answers>
>> # Not doing Q(com, CAA) as we already did it; if it was example.net, we
>> would do Q(net, CAA) here
>> Result: no CAA record found
>>
>
> I think this still will have unexpected results.
>
> See this real world example:
>
> ;; QUESTION SECTION:
> ;; www.paypal.com. IN A
>
> ;; ANSWER SECTION:
> www.paypal.com. 453 IN CNAME www.paypal.com.akadns.net.
> www.paypal.com.akadns.net. 30 IN CNAME ppdirect.paypal.com.akadns.net.
> ppdirect.paypal.com.akadns.net. 180 IN CNAME wlb.paypal.com.akadns.net.
> wlb.paypal.com.akadns.net. 30 IN CNAME www.paypal.com.edgekey.net.
> www.paypal.com.edgekey.net. 0 IN CNAME e3694.a.akamaiedge.net.
> e3694.a.akamaiedge.net. 20 IN A 23.13.156.181
>
> If paypal.com sets a CAA record to symantec.com, but edgekey.net has a
> CAA record to megaca.xyz, then the result is that Symantec cannot issue
> for www.paypal.com but MegaCA can (and only MegaCA can).  I don’t think
> that this is the logical result.
>
> While I do support CAA, I think we need to fix/clarify the handling of
> CNAMEs before mandating CAs follow CAA directives.
>

Hi Peter,

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.

Considering example.com, which might set a CAA record to symantec.com. This
is because the example.com operator knows that all of the certificates they
will obtain/purchase/etc will be from Symantec. Now imagine there's a
subdomain - shop.example.com . This domain is part of the example.com
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 example.com's branding.

A key point of this being that shop.example.com is not operated by the
example.com operator, but instead CNAMEs over to
shop.example.com.shopcorp.example, perhaps with as many hops as you've
pointed out.

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 shop.example.com. So shopcorp.example has a CAA record
of saying MegaCA.

The logical consequence of this means that Symantec cannot issue for
shop.example.com, only MegaCA can. But that's exactly what is intended and
logical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170225/88188197/attachment-0003.html>