[cabfpub] Draft CAA motion (4)

Ryan Sleevi sleevi at google.com
Tue Jan 24 13:59:03 MST 2017


On Tue, Jan 24, 2017 at 12:03 PM, Doug Beattie via Public <
public at cabforum.org> wrote:

> Create Appendix A – CAA checking
>
> 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:
> Let
> 1. CAA(X) be the record set returned in response to performing a CAA
> record query on the label X,
> 2. P(X) be the DNS label immediately above X in the DNS hierarchy, and
> 3. A(X) be the target of a CNAME or DNAME alias record specified at the
> label X.
> Then:
> 1. If CAA(X) is not empty, R(X) = CAA (X), otherwise
> 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
> 3. If X is not a Base Domain Name, then R(X) = R(P(X)) and perform check
> again starting at step 1, otherwise
> 4. R(X) is empty.
>
> • 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.
> • 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
> • 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.
>

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").

I'm hoping you can expand upon your goals here, so we can find a better way
to accomplish them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170124/af06303d/attachment.html>


More information about the Public mailing list