[cabfpub] Continuing the discussion on CAA

[Ryan Sleevi]

On Tue, Oct 25, 2016 at 7:54 PM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Although CAA was designed around DNS, the actual record isn’t relevant DNS
> information.
>

I believe this is irrelevant. We're discussing scope of authority, not the
presented information. DNS's scope of hierarchal authority flowing down
involves delegating authority at each subordinate, which is why CAA works
from the most authoritative scope (the fully qualified domain) and then
works upwards.


>  A simpler way to do this would simply have the base domain indicate
> whether the policy applies to all other domains.
>

I appreciate your perspective, but I disagree. We (Google, the Internet
community) have substantial experience in such 'top-down' policy
expressions, via methods such as HSTS and HPKP, and we repeatedly receive
concerns about that approach.

A concrete example of why I believe this is fundamentally a flawed design,
and do not support it, is situations where '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.

Further, I want to challenge your notion of 'base domain', which I know you
mean in good intent, but for which I tried to highlight in my previous
message is problematic in scope and determination. As you know,
dependencies on the public suffix list are not at all desirable, in the
general case, and there is substantial ambiguity and difference between
information expressed in WHOIS (which I believe you're referring to,
inasmuch as you mean 'registerable domain') and that expressed in DNS.


> This is already permitted in CAA with wildcards so simply adding a tag
> that specifies “apply to all domains” would be easier (Indeed – the spec is
> designed for this). How about PHB adds a tag of “base-approval=1” as a flag
> to indicate all superior labels are considered approved IF the flag is set.
> If the flag is not set, validation would have to occur at each node.
>

I've tried to explain why I believe your proposal is technically unsound
and unworkable, but perhaps we're simply not communicating. I do encourage
you to re-read the CAA spec, however, because your description of wildcards
and tags is something that is quite ambiguous and problematic, so it would
help if you could be more precise in your terms.

For example, your suggestion that PHB "add a tag" is, as explained on past
discussions, unnecessary. In CAA, there are are 'parameter tag' (also
called 'property tag'), such as 'issue', which are additive. That is, they
expand the scope, not restrict it. Within a given 'issue' or 'issuewild'
parameter tag, you can have issuer-parameters, but those are defined to
further constrain the issuance, which again, is the opposite of what you
intend.

I'm trying to highlight that there are substantial technical concerns, and
resolving them to accommodate what you propose would require significant
IETF action, even if they were agreed upon as desirable, which I do not
believe they are. Further, I do not believe it aligns with what we
concretely and empirically know about the experience and desires of site
operators, both with respect to CAA and in related policy expressions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20161025/9deaf864/attachment.html>