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

[Tim Hollebeek]

Thanks Corey.  I noticed this flaw as well 😊  On a recent public call, we decided to handle issues CAs are having with CAA under the validation group, so you’re in the right place!

 

The good news is I think this is another case where the original intent is obvious, even if the grammar is written incorrectly.  I would suggest that any CAs implementing this follow the “1 or more spaces” interpretation to avoid confusion.  We can discuss that on the next validation call, and if everyone agrees about that, we start discussing filing an errata with the IETF folks.

 

Also note that there may *never* be a date when CAs are required to support this proposal.  It will work fine as a completely voluntary initiative that CAs can join as their schedule allows.  This is more of a standardization for the purpose of interoperability and avoiding confusion, than it is a security requirements thing.

 

-Tim

 

From: Validation [mailto:validation-bounces at cabforum.org] On Behalf Of Corey Bonnell via Validation
Sent: Friday, December 15, 2017 9:10 AM
To: validation at cabforum.org
Subject: [cabf_validation] Ambiguous grammar for parameters in RFC 6844 (CAA)

 

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

 

2017 Best Managed Security Service Winner – SC Media

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20171215/a0a007fa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20171215/a0a007fa/attachment-0001.p7s>