<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 25, 2016 at 7:54 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-4382948024473374462WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Although CAA was designed around DNS, the actual record isn’t relevant DNS information. </span></p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-4382948024473374462WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> A simpler way to do this would simply have the base domain indicate whether the policy applies to all other domains. </span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>A concrete example of why I believe this is fundamentally a flawed design, and do not support it, is situations where '<a href="http://example.com">example.com</a>' 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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_-4382948024473374462WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">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.</span></p></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div><br></div></div>