[cabf_validation] Ambiguous grammar for parameters in RFC 6844 (CAA)

[Corey Bonnell]

In order to prepare for reading Tim’s proposal on CAA parameters, I took a further look into the grammar of parameters in issue/issuewild records as defined in section 5.2 of RFC 6844 (https://tools.ietf.org/html/rfc6844#section-5.2) and realized that the ABNF grammar is ambiguous. Specifically, the ABNF grammar as written does not require that parameter tag/value pairs be delimited by whitespace, which can lead to ambiguous parses of parameters.

Here are the relevant production rules from section 5.2:
issuevalue = space [domain] space [";" *(space parameter) space]
space = *(SP / HTAB)
parameter = tag "=" value
tag = 1*(ALPHA / DIGIT)
value = *VCHAR

The salient piece here is that the “space” production rule is defined as a sequence of *zero* or more space or horizontal tab characters, which means that multiple parameters can be delimited by 0 space characters (in other words, they’re not delimited at all). Since the character “=” is a VCHAR, this can lead to ambiguous parses of parameter strings such as “a=bc=d” (is that one parameter with a tag of “a” and a value of “bc=d”, or is it two parameters with a tag of “a” and a value of “b” and a tag of “c” and a value of “d”?). As a practical example using the proposed parameters in Tim’s proposal, the parameters string “validation=Phonetype=EV” (which is very possible if the customer accidentally omits the space between “Phone” and “type”) would parse to either a parameter tag of “validation” and a value of “Phonetype=EV”, or it would parse to parameter tag of “validation” with a value of “P” and a parameter tag of “honetype” with a value of “EV”.


A quick fix for this ambiguity is to redefine the “issuevalue” and “space” production rules such that at least 1 space character is required between parameters (there probably is a more elegant way to express this, but here’s the general idea):
issuevalue = [space] [domain] [space] [";" [space] [parameters] [space]]
space = 1*(SP / HTAB)
parameters = (parameter space parameters) / parameter

I believe it’s important that this ambiguity be resolved before CAs are required to honor various CAA parameters. Otherwise, there will be much confusion when CAs have different (but equally valid) interpretations of the same CAA record’s parameters.

Since there is no “formal” CAA working group, I’m not sure if we want to present this finding to the LAMPS WG so that the appropriate changes can be made to RFC 6844-bis, or if we want to handle this in another manner.

Thanks,
Corey

Corey Bonnell
Senior Software Engineer

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

2017 Best Managed Security Service Winner – SC Media
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171215/cce308a8/attachment.html>