<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 27, 2016 at 8:33 PM, Peter Bowen via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I propose that this be mitigated by adoption a two prong rule for CAA:<br></div><div>1) By default CAs must treat the presence of CAA records which do not include them as “hard fail” and not issue</div><div>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.</div><div>The CA must internally log any certs that are issued after a “soft fail” and report such via any iodef in the CAA record.  </div></div></blockquote><div><br></div><div>Your last sentence regarding iodef suggests you believe this isn't already required.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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,</div></div></blockquote><div><br></div><div>I'm sorry, but I'm going to specifically object to this statement. It's not been shown to be slow - merely, some members have postulated that it "might" be slow, without showing concrete evidence or data to the contrary, and in the face of experience otherwise.</div><div><br></div><div>If members want to support this line of inquiry, data needs to be provided.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.</div><div>2) extending the “domain” definition to be (<span><font size="2">label *("." label)) / “*”; a “*” is an explicit declaration that there is no CA restriction (the </font></span><font size="2">opposite of an empty domain name)</font></div><div><font size="2">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.  If they find such a record, they may use that record and not check any further labels.</font></div></div></blockquote><div><br></div><div>I am not supportive of any of these changes, nor is the CA/Browser Forum the venue for them.</div><div><br></div><div>As has been pointed out elsewhere on the thread, the CAA spec is intentionally rather explicit in prohibiting your #3 with respect to precedence, even if they can be queried in that order (or in parallel). Considering that changing the tokenization rules has concrete impact on applications and CAA implementations, I do not believe your #2 is at all compatible with deployments or implementations, and is thus unlikely to be adopted (and certainly, something to object to)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><font size="2">This should allow customers who have a need for massive issuance rates of unique hostnames to enter a CAA record at the common suffix label allowing the CA to have a near 100% cache hit rate on DNS look ups.</font></div></div></blockquote><div><br></div><div>This seems a premature optimization based on unfounded concerns from those without implementation experience. As such, I have trouble weighting this request at all as reasonable.</div><div><br></div></div><br></div></div>