[cabfpub] Continuing the discussion on CAA

Eneli Kirme Eneli.Kirme at sk.ee
Wed Oct 26 05:38:03 UTC 2016


In practice CAA record are subject to be manipulated by UI provided by DNS records management. We have no way to control it and once there is a “default” listed for customer convenience then the damage for fair market has been placed. Without actually much thinking customers make a business decision of one area in the context of another without much thinking about it.
Can we from CABForum somehow protect against such “defaults”?

Best regards,


On 26 Oct 2016, at 06:08, Ryan Sleevi via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:

On Tue, Oct 25, 2016 at 7:54 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto: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<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.

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.

Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20161026/1e6aacaf/attachment-0003.html>

More information about the Public mailing list