<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 24, 2017 at 12:03 PM, Doug Beattie 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">Create Appendix A – CAA checking<br>
<br>
The following is pulled from RFC 6844 and expanded on slightly to clearly define the precise checks that MUST be performed for BR compliant CAA checking:<br>
Let<br>
1. CAA(X) be the record set returned in response to performing a CAA record query on the label X,<br>
2. P(X) be the DNS label immediately above X in the DNS hierarchy, and<br>
3. A(X) be the target of a CNAME or DNAME alias record specified at the label X.<br>
Then:<br>
1. If CAA(X) is not empty, R(X) = CAA (X), otherwise<br>
2. If A(X) is not null (i.e, there is a CNAME or DNAME record for X), and R(A(X)) is not empty, then R(X) = R(A(X)), otherwise<br>
3. If X is not a Base Domain Name, then R(X) = R(P(X)) and perform check again starting at step 1, otherwise<br>
4. R(X) is empty.<br>
<br>
• If any one of the returned records in R(X) contains a Domain Name from the set of the CA’s Issuer Domain Names, then the CA may issue the certificate.<br>
• If none of the records returned in R(X) contain any Domain Name from the set of the CA’s Issuer Domain Names, then the CA MUST NOT issue the certificate<br>
• If a CNAME or DNAME record is found, then the CAA check will start over using the returned value as the new input to the CAA check.<br></blockquote><div><br></div><div>Google's experience with specifications is that we're generally strongly opposed to this approach of copying and modifying portions of specifications (known as "monkey patching").</div><div><br></div><div>I'm hoping you can expand upon your goals here, so we can find a better way to accomplish them.</div></div><br></div></div>