[cabfpub] CAA: Interpretation of 3.2.2.8 + 3.2.2.5

[Ryan Sleevi]

I received a question from an auditor regarding CAA that I thought best
directed through to the broader Forum, both to ensure it's a consistent
interpretation with the BRs and to see if there is any disagreement with it.

The question they raised is as follows (slightly edited)

Section 3.2.2.5#3, allows CAs to perform a reverse lookup of the IP, verify
> control of the resulting Domain Name, and issue a certificate. In such a
> situation, does the CA have to perform a CAA check on the “reverse
> looked-up” domain name? Because 3.2.2.8 only requires CAA check for each
> _dNSName_ in the SAN.
>
> Most of the certs I see include both the ipAddress and the associated
> domain name in the SAN, so those will be fine (most of the time).
>
> However, if the cert does not contain the domain name associated with the
> ip, is a CAA check required? i.e., does such a cert pose any risk to the
> domain holder (from a BR/Browser perspective)?
>
> E.g., SAN: dNSName: example.com, ipAddress: 50.50.50.1
> RevLook(50.50.50.1) = example.net


The BRs are unambiguous that "example.com" must have CAA checked for it (it
appears in the dNSName). However, should example.net have CAA checked prior
to issuing for the equivalent IP?

I believe the answer is "No", for the following reasons:

1) The language in 3.2.2.8 is clear it applies to the dNSName, so I don't
think I can argue for an interpretation that suggests it applies to
3.2.2.5, as worded :) Whether we intended it to or not is a separate
discussion, but whether it does or not, at present, is clear :)

2) The CAA check does not meaningfully add security, because the
certificate could have been obtained under 3.2.2.5 (Methods 1, 2, 4), all
of which would have bypassed any restrictions on CAs.


As such, if you desire an IP-address bearing certificate, there is no means
you can use to limit the CAs who can issue or (by virtue of the CA-specific
extensions) any policies that the issuing CAs use to verify or authenticate
the request.

Does this conclusion feel correct for others?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170828/6d327271/attachment.html>