[cabfpub] Ballot 187 - Make CAA Checking Mandatory

Ryan Sleevi sleevi at google.com
Sat Feb 25 18:59:38 UTC 2017


Once again, forwarding replies on their behalf. I'm hopeful Gerv will
comment as well

On Fri, Feb 24, 2017 at 3:08 PM, Ryan Sleevi <sleevi at google.com> wrote:

> Reposting their reply (below)
>
> On Fri, Feb 24, 2017 at 12:36 PM, Ryan Sleevi <sleevi at google.com> wrote:
>
>>
>> I believe this question is highlighting whether "operate" represents
>> being the authoritative name servers versus practical demonstration of
>> control. Alternatively, we might pose the question as "Does demonstration
>> of control of _a_ record equivocate to demonstration of control of the CAA
>> record", if I understand the question correctly.
>>
>> My belief and support is that the intent of "operated by the CA or an
>> Affiliate of the CA" was to match the terminology from RFC 7719, which
>> would specifically mean the interpetation (b), and the answer to the
>> hypothetical question is "No, demonstration of control of a record is not
>> sufficient, demonstration of operation of the authoritative name servers is"
>>
>> Is that consistent with the intent Gerv? If so, does that look like
>> something you see as easy to correct? I'm wondering whether introducing RFC
>> 7719 as the normative dependency might provide better clarity to this
>> question.
>>
>
> """
> But is that the right thing to do though? Meaning if I manage my DNS
> records through Example A’s DNS management portal (or whatever it is
> called), but set a CAA record that only allows Example B to issue certs to
> my domain (assume my website is hosted in AWS), can they still issue certs
> to my domain without checking the records? Sorry if I’m missing something
> obvious.
> """
>
> My view is that Example CA (who is operating the DNS service), and who is
> running the authoritative responder (e.g. they are the DNS operator), can
> totally cause issuance through any number of means - such as manipulating
> the WHOIS, introducing/modifying the CAA record, etc.
>

"""
- I agree with the above that a DNS operator can cause issuance, but a
honest CA+DNS operator wouldn’t do it (at least knowingly) and a rogue CA
doesn’t really need control over the DNS to issue a bad/malicious cert. As
I understand it, CAA wouldn’t stop a rogue CA from issuing a cert.
"""


>
> That said, I recognize there's a difference between technically capable
> versus being appropriate, and I doubt that the applicant/subscriber could
> enter into a contractual relationship with Example CA's DNS operating arm
> (which might be an Affiliate) that prevents Example CA's CA arm from
> ignoring CAA. However, we also identified the "Microsoft" case (as it were;
> although similar for Google and Apple, operationally speaking), in which
> the subordinate CA certificate is operated by the same organizational
> entity managing the DNS, and it may make less sense to require checking.
>
> Thoughts?
>

"""
- I believe the statement in question was introduced to address what you
mentioned above; not having to check CAA record for domains that the CA (or
its organization) owns/controls. Wouldn’t it be simpler if CAA check is
made optional only in such a situations “where the CA or Affiliate owns or
controls the domain” instead of introducing DNS operator into the mix. Or
are there other CA+DNS service provider who are requesting that CAA check
be made optional for them?
"""


>
> My own is I'd be willing to deal with the increased risk (that comes from
> using "Example CA"'s DNS services, which would allow them to potentially
> issue a certificate in contravention of my CAA record), so long as it could
> be clear as a domain holder that I'm accepting that risk. If I didn't want
> it, I'd just choose to operate my DNS from someone who is not a CA
> (assuming I could determine that).
>

"""
- Once again, I see this differently, as in, honest_Example CA wouldn’t do
this and rogue_Example CA doesn’t need to manipulate CAA record to issue a
certificate. Did I get that wrong?
"""
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170225/1f73d8db/attachment-0003.html>


More information about the Public mailing list