Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

From: Ryan Sleevi <[email-masked]>
Date: Fri, 2 Feb 2018 19:39:41 -0500

On Fri, Jan 12, 2018 at 4:41 PM, Corey Bonnell <[email-masked]>
wrote:

> Hello,
>
> I believe that there are several ambiguities in RFC 6844 in regard to
> processing CAA resource record sets that do not contain "issue" records.
>
>
>
> Section 3 of RFC 6844 (http://www.rfcreader.com/#rfc6844_line196) defines
> the "issue" property tag to authorize "the holder of the domain name
> <Issuer Domain Name> or a party acting under the explicit authority of the
> holder of that domain name to issue certificates for the domain in which
> the property is published". Based on my interpretation, the definition
> given here is suggesting that CAA issue restriction processing is done
> regardless of whether or not there is an "issue" record(s) present to
> specify the set of permitted Issuer Domain Names. In other words, the lack
> of "issue" records in a CAA resource record set indicates that no CA may
> issue for that domain, since no CA has been authorized to issue.
>
>
>
> However, section 5.2 (http://www.rfcreader.com/#rfc6844_line447) defines
> the "issue" property tag to "request that certificate issuers perform CAA
> issue restriction processing for the domain and to grant authorization to
> specific certificate issuers". Based on this definition, it sounds as if
> CAA issue restriction processing is "opt-in". In other words, the absence
> of "issue" records in a CAA record set indicate that any CA may issue for
> that domain (since there was no "opt-in" into CAA restriction processing).
>
>
>
> Section 4 (http://www.rfcreader.com/#rfc6844_line288) states that,
> "before issuing a certificate, a compliant CA MUST check for publication of
> a relevant CAA Resource Record set." Unfortunately, the term "relevant" is
> not defined by the RFC, which, compounded with the ambiguity highlighted
> above in regard to the definition of the "issue" property tag in sections 3
> and 5.2, leads to ambiguity in the handling following scenarios:
>
>
>
> - A CAA resource record set consisting solely of unknown non-critical
> property tags (including misspellings of "issue", such as "iisue", etc.)
>
> - A CAA resource record set consisting solely of "iodef" property tags
>
> - A CAA resource record set that contains both of the above
>
>
>
> For each of these cases above, it is unclear which of the following three
> actions a CA should take:
>
> - Fail issuance (since the CAA resource record set did not authorize any
> CA to issue, given the definition of the "issue" property tag in Section 3)
>
> - Continue the tree-climbing search for records (since the resource record
> sets above could conceivably be considered as "not relevant")
>
> - Allow issuance (since the resource record sets above could conceivably
> be considered as "relevant" and any CA may issue, given the definition of
> the "issue" property tag in section 5.2)
>
>
>
> At Trustwave, we have taken the conservative approach and will not issue
> certificates if we encounter CAA resource record sets matching the
> descriptions of the three above. However, given that we may be overly
> restrictive by doing this, as well as for a desire for CAA record sets to
> be processed uniformly regardless of the CA, we would like to see these
> ambiguities resolved.
>
>
>
> If others agree that the current wording of the RFC is ambiguous, I would
> be happy to present changes to relevant sections to clear up the ambiguity,
> but for now I wanted to send this along to see if others share our
> interpretation of the RFC.
>
>
>
It's not clear to me that "relevant" is not defined by the RFC, given the
following:
  "Given a request for a specific domain X, or a request for a wildcard
   domain *.X, the relevant record set R(X) is determined as follows:"
combined with
  "Let CAA(X) be the record set returned in response to performing a CAA
   record query on the label X,"

The natural consequence of this is a hierarchy such that
subdomain1.subdomain2.example.com. IN CAA 0 iodef "mailto:
[email-masked]"
subdomain2.example.com.                             IN    CAA 0 issuewild
";"
example.com.                                                  IN    CAA 0
issue "ca.example.com"

Means that subdomain1.subdomain2.example.com. is unrestricted by issuance
(i.e. the parent's restrictions do not apply) because the relevant record
set does not contain an issue field.

Similarly, subdomain2.example.com is prohibited from wildcards, but
otherwise, any CA can issue (e.g. example.com's restrictions do not apply)

However, example.com, and all subdomains *other than*
subdomain1.subdomain2.example.com, subdomain2.example.com, and *.
subdomain2.example.com are otherwise restricted

---

From: Tim Hollebeek <[email-masked]>
Date: Sat, 3 Feb 2018 00:55:22 +0000

> It's not clear to me that "relevant" is not defined by the RFC, given the following:

I agree, and in my response I made it clear that “relevant” clearly indicates the record set retrieved via the described algorithm.  The wording isn’t the best, but I think that part is clear.

> Means that subdomain1.subdomain2.example.com <http://subdomain1.subdomain2.example.com> . is unrestricted by issuance (i.e. the parent's restrictions do not apply) because the relevant record set does not contain an issue field.

Unfortunately, I do not believe this is clear, despite it being clear that this was the intent.  There’s explicit text that says that if there’s no record set is returned issuance is allowed.

There is also text that states that if an issue record includes the CA, issuance is allowed.

An overly literal reading of the text would indicate that in the absence of either of those two conditions (the record set is non empty and there is no issue tag that allows issuance),

then issuance is not allowed.  As I pointed out in my analysis, this reading of the text is inconsistent with text elsewhere in the RFC, and that your analysis correctly identifies what the

RFC *intended* to say.

Therefore I support Corey’s errata to make it clear that the RFC says what we all seem to agree it was intended to say.  Just to avoid any unnecessary compliance silliness.

-Tim