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

Jacob,
Thank you for getting this erratum included in RFC 6844-bis. It will be good to get the wording cleared up.

As for my original erratum text not specifying "issuewild", that is because section 5.3 (5.3.  CAA issuewild Property) specifies that "The issuewild property has the same syntax and semantics as the issue property except that issuewild properties only grant authorization to issue certificates that specify a wildcard domain". Given that issuewild property tags have the same semantics as issue property tags, the addition of my original erratum text (in section 5.2, which defines issue property tag semantics) will also address the case of a resource record set not containing issue property tags and not containing issuewild property tags (only in the case of wildcard domain names, since issuewild property tags are otherwise ignored as per section 5.3).

If you think that's too vague and it's better to explicitly mention the lack of issuewild tags, we should qualify the language a bit to say "A non-empty CAA record set that contains no issue property tags (and also does not contain any issuewild property tags when performing issue restriction processing for a wildcard domain) is authorization to any certificate issuer to issue for the corresponding domain, provided that no records in the CAA record set otherwise prohibit issuance." Otherwise, it is unclear how to handle the case of a non-empty CAA record set for a non-wildcard domain that does not contain an issue property tag but contains one or more issuewild property tags.

Thanks,
Corey

Corey Bonnell
Senior Software Engineer
t: +1 412.395.2233

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Date: Monday, March 26, 2018 at 7:49 PM
To: Corey Bonnell <CBonnell@trustwave.com>, "spasm@ietf.org" <spasm@ietf.org>
Subject: Re: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

I've written this up as a PR: https://github.com/jsha/caa-simplification/pull/1/files<https://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHvf0GuoOkjQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fjsha%2fcaa-simplification%2fpull%2f1%2ffiles>. If there are no objections, I'll merge it in a week for the 6844bis draft.

Note that I tweaked it slightly from your erratum (https://www.rfc-editor.org/errata/eid5244<https://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHvf0Ev9GmjQ&s=5&u=https%3a%2f%2fwww%2erfc-editor%2eorg%2ferrata%2feid5244>). Where you referred just to "issue" property tags, I mention both "issue" and "issuewild."
On 01/12/2018 01:41 PM, Corey Bonnell 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<http://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHva1WuNSniQ&s=5&u=http%3a%2f%2fwww%2erfcreader%2ecom%2f%23rfc6844%5fline196>) 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<http://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHvftXvYf33g&s=5&u=http%3a%2f%2fwww%2erfcreader%2ecom%2f%23rfc6844%5fline447>) 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<http://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHvfNVvND12Q&s=5&u=http%3a%2f%2fwww%2erfcreader%2ecom%2f%23rfc6844%5fline288>) 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.

Thanks,
Corey

Corey Bonnell
Senior Software Engineer
t: +1 412.395.2233

Trustwave | SMART SECURITY ON DEMAND
www.trustwave.com<http://www.trustwave.com/>

2017 Best Managed Security Service Winner – SC Media

_______________________________________________

Spasm mailing list

Spasm@ietf.org<mailto:Spasm@ietf.org>

https://www.ietf.org/mailman/listinfo/spasm<https://scanmail.trustwave.com/?c=4062&d=loe52jNi8V2QtLlmCxq-y_nbkZ0r54DHvfJV7oWjjQ&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2fspasm>