[cabfpub] Continuing the discussion on CAA

[Jeremy Rowley]

Thanks Gerv. "Subdomains" is a much better tag than the validation property I 
proposed in the email last night.

The scenario you described is exactly the one I'm trying to solve. Although 
the <customerID>.example.com scenario you describe is uncommon ( I wouldn't 
say rare) on a customer basis, it's a large percentage of the number of 
certificates.

-----Original Message-----
From: Gervase Markham [mailto:gerv at mozilla.org]
Sent: Wednesday, October 26, 2016 3:37 AM
To: Ryan Sleevi <sleevi at google.com>; Jeremy Rowley
<jeremy.rowley at digicert.com>
Cc: public at cabforum.org
Subject: Re: [cabfpub] Continuing the discussion on CAA

On 26/10/16 04:08, Ryan Sleevi wrote:
> A concrete example of why I believe this is fundamentally a flawed
> design, and do not support it, is situations where 'example.com
> <http://example.com>' delegates subdomains to different marketing
> companies, who are then responsible for hosting and providing the
> content on those subdomains. Expressing CAA in this 'top down'
> approach means that, for the 'base domain', you must express the union
> of all possible CAs. We know, empirically, this is not viable.

Indeed, it would be unwise to change CAA to _only_ work this way.

> Further, I want to challenge your notion of 'base domain',

I agree that making correct implementation of CAA depend on the PSL is
problematic - the more we can avoid using the PSL, the better.

Here is a straw-man proposal which does not require use of the PSL, although
it does require some caching outside of DNS in the case where the new feature
is used.

I don't think this solution is the most elegant technically, but Jeremy raises
the reasonable point about "what if I have to issue N million certs for
1.example.com, 2.example.com etc.?" Because caching doesn't help here, you
would have to do a full CAA check from scratch for everyone one of the N
million. This is a rare situation, to be sure, but I can see how it might be
problematic when it does occur.

So here's the idea:

1) CA is asked to issue for foo.bar.example.com
2) CA does CAA check for foo.bar.example.com - no record
3) CA does CAA check for bar.example.com - no record
4) CA does CAA check for example.com - record found

The record is "issue 0 superca.com; subdomains=true"

What this means is that Super CA is permitted to use this CAA record for all
issuances under example.com for the TTL specified on the DNS CAA record,
without doing further CAA checks on subdomains. Once that TTL expires, the
process would begin again from scratch.

The obvious question which arises then is: what happens when records conflict?
Say a few minutes after the above events, example.com adds a CAA record for
bar.example.com saying "issue 0 ahmedscerts.com". The answer is that the CA is
allowed to use the cached info about example.com for the DNS TTL, and after
that they re-check CAA from scratch, and hit this record, and so never get as
far as checking example.com. They instead refuse to issue, because only
Ahmed's Certs is allowed to.

OK, you ask, so what happens if the next domain they check is
wibble.example.com, which eventually gives them back the example.com CAA
record with "subdomains=true", and then they cache that, and use it to issue
later for bar.example.com, in "violation" of the CAA record attached directly
to bar.example.com? The answer is "don't put conflicting CAA records into your
DNS if you want defined and predictable behaviour". But it still remains true
that even in the worst and most badly configured case, the only CAs which can
issue anywhere under example.com are the ones named in a CAA record somewhere
within the domain, which is still a massive improvement on the current
situation.

Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20161026/ca951be3/attachment-0001.bin>