[cabfpub] CAA concerns (and potential solutions)

[Peter Bowen]

> On Oct 28, 2016, at 3:50 AM, Gervase Markham <gerv at mozilla.org> wrote:
> 
> Hi Peter,
> 
> On 28/10/16 04:33, Peter Bowen via Public wrote:
>> I propose that this be mitigated by adoption a two prong rule for CAA:
>> 1) By default CAs must treat the presence of CAA records which do not
>> include them as “hard fail” and not issue
>> 2) However, if the CA has issued an Enterprise EV RA certificate
>> containing a valid authorization domain, logged it in at least <n>
>> public CT logs, the CA may treat CAA for those FQDNs and Wildcard DNs
>> matching the authorization domain as “soft fail” and issue even if the
>> CAA record specifies otherwise.
> 
> I think this is a plausible solution. But if CAs are going to be allowed
> to issue in contradiction to CAA, why make them check CAA in this case
> at all?

It is clear there is a lot of uncertainty out there about CAA.  One of the concerns is that this left hand not knowing what the right hand is doing scenario is common.  By requiring checking CAA and logging when it is being overridden, we can move to certainty.  I think CAs should track this so we can come back in a year and review how often allowing soft-fail had any impact.  I would hope that those advocating soft-fail would feel better about moving to universal hard-fail if it was found that it would have impacted zero issuances over the last six months.  Conversely, I hope that those advocating hard-fail would be more open to long term soft-fail or simply not checking if it turns out that 5% (or 25%) of issuances would have been impacted.

To be clear, my proposal is designed to be a compromise that doesn’t get anyone what they want long term.  I’m hoping that we can agree to *something* that would start measuring impact and provide value for those organizations that want CAA.

> Would it not also resolve this, and the issue Jeremy raises
> about the CA being the registrant, if CAA checks were not compulsory for
> leaf certs under technically-constrained enterprise intermediates
> disclosed in the way given above? What would be the downsides of that?

This is about Enterprise RAs not Enterprise Subordinates. 

> Would it help to mark such intermediates with a policy OID to make it
> clear to the world that different rules apply to its leaf certs?

Enterprise RAs don’t have intermediate certificates.  Certificates authorized by an Enterprise RA are issued from CA operated by an organization separate from the RA.  See my email to Bruce.

>> The second concern is around issuance latency.  If a certificate has
>> dozens of subject alternative names or a CA is issuing massive number of
>> certificates the full CAA checking algorithm can be slow, especially if
>> there are no CAA records as each label must be checked back to the root.
> 
> On that point: I suggested on the call (after the official end) that the
> standards might permit (but not require) an optimisation such that it
> was not required to check CAA for suffixes in the ICANN section of the
> PSL. That prevents you spending your time looking up the CAA record for
> ".com" millions of times.

That is a possible optimization. My personal testing showed lookups against a local cache were really cheap, so I didn’t include that.

>> 1) a new parameter tag for issue and issuewild properties:
>> “skipsubdomaincheck" which can be “true” or “false”.  The default value
>> is “false”.  If true, it indicates that a CA may skip checks for more
>> specific subdomains.
>> 2) extending the “domain” definition to be (label *("." label)) / “*”;
>> a “*” is an explicit declaration that there is no CA restriction
>> (the opposite of an empty domain name)
> 
> This second point seems to me to be orthogonal to solving the problem
> you raise; can you explain why it's integral to it?

If the objective is speed, and the domain owner really wants to just optimize for speed with no restriction on who can issue, then they put the following record in at the top-most point they control (e.g. the registered domain apex):

@ IN CAA 0 issue “*”; skipsubdomaincheck=true

Without the “*” option, if a domain owner does not want to indicate CA restriction, then every label in every FQDN has to be checked.

>> 3) CAs may choose to check starting at the TLD and working their way
>> down the tree of labels rather than starting with all labels and working
>> towards the root.  If they choose this option they must use the most
>> specific CAA record found unless they find a record with
>> skipsubdomaincheck=true.
> 
> So to be clear: in the absence of skipsubdomaincheck=true, which we
> would expect to see only on a small number of domains which have a very
> large number of subdomains each, the result would be the same as the
> current CAA algorithm - although perhaps calculated less efficiently.

Yes.  That is why this is a “MAY”.  I would expect that most CAs would use the algorithm in the RFC and only enable the “reverse” algorithm when they had a very high confidence that they would find a directive with skipsubdomains=true.

Thanks,
Peter