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

[Tim Hollebeek <[e-mail]>]

So the problem at hand is the difference between CAA records that don’t exist (case A), and CAA records that exist but have no “issue” records (case B).  I’ll discuss the following subcases:

 

Case B1: ihatewildcards.example.com    CAA 0 issuewild “;”

 

Case B2: ineedcoffee.example.com          CAA 0 isue “digicert.com”

 

Your interpretation of Section 3 cannot be the intent of the RFC because it would render language elsewhere unnecessary (specifically, language like “the issue property tag is used to request that certificate issuers perform CAA issue restriction” that you noted).  I think the root of the ambiguity is the first paragraph of Section 4 where it says “consistent with the applicable CAA Resource Record set”.  I think it’s clear that despite having no definitions, “applicable Resource Record set” and “relevant record set” both refer to the results of the search algorithm specified in Section 4.  

 

In case A, that set is empty (see the last bullet point), in which case the “If such a record set exist, …” in the previous sentence makes the interpretation clear.  Issuance is allowed.

 

In case B, the set is not empty, so we’re left with what “consistent with” means.  And that’s subject to interpretation.  However as noted above, I think the intent is clear.  The RFC even goes out of its way to describe an alternative syntax for “Do not issue” (namely, ‘issue “;”’), so there is no need for lack of an issue tag to mean do not issue, as it would become semantically redundant with issue “;”.

 

The “no issue tag means no restrictions” interpretation allows you to express the “no restrictions” policy, which cannot be expressed in any other way without listing every CA out there, including ones that don’t exist yet.

 

The “no issue tag means no issuance” case breaks the important use case B1, which specifies that normal certificates are fine but wildcards are not.

 

The only case that can be made in favor of the “no issue tag” meaning no issuance is case B2, but the correct way of fixing that is to mark tags that you don’t want to be ignored as critical.  If you mark your issue tags critical, they will fail closed as desired.

 

So, in summary, I think the intent of the RFC is clear, and there is a perfectly reasonable interpretation of “consistent with” that is … uh … consistent with that intent 😊, and that “CAA restriction processing” (used twice) must be requested by including an “issue” tag (or “issuewild” [1]) before any request can be inconsistent with the returned record set.

 

As always, CAs are free to be more restrictive with issuance than required, but in this case I think the looser interpretation is better since it agrees with the intent and allows important use cases like B1.  It also will be important for the upcoming CAA tags as you will need to be able to express “I’m fine with any CA, as long as they don’t use method 5.”

 

I’ll add it to the Validation WG agenda for this week so we can see what other CAs think.

 

-Tim

 

[1] The description of “issuewild” states that it has the same semantics as “issue”, so it also requests CAA issue restriction processing.

 

From: Spasm [mailto:[e-mail]] On Behalf Of Corey Bonnell
Sent: Friday, January 12, 2018 2:41 PM
To: [e-mail]
Subject: [lamps] Ambiguities in RFC 6844 regarding CAA resource record sets with no "issue" property tags

 

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.

 

Thanks,

Corey

 

 

 

Corey Bonnell

Senior Software Engineer

t: +1 412.395.2233

 

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

 

2017 Best Managed Security Service Winner – SC Media