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

Fri Dec 15 13:36:38 MST 2017

Ugh.  I thought I had figured out the usage of semi-colons and whitespace but obviously there are more gremlins in there than I had thought.

I think I agree with the errata since it agrees with me 😊.  But yeah, we should get this all figured out.

I have also privately received some feedback that perhaps some of these CAA tags (e.g. not account) would be better off at the top level.  For example:

0 CAA issue ca1.com

0 CAA issue ca2.com

128 CAA dcv Phone

This would allow the critical flag to be used, and would greatly reduce the need for multiple name value pairs.

-Tim

From: Corey Bonnell [mailto:CBonnell at trustwave.com] 
Sent: Friday, December 15, 2017 1:17 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/Browser Forum Validation WG List <validation at cabforum.org>
Subject: Re: Ambiguous grammar for parameters in RFC 6844 (CAA)

Hi Tim,

Unfortunately, I think the original intent is a bit unclear, as section 3 (https://tools.ietf.org/html/rfc6844#section-3) has the syntax listed as such:

issue <Issuer Domain Name> [; <name>=<value> ]*

In other words, section 3 indicates that parameters are delimited using semicolons (and not whitespace, as section 5.2 would indicate if it had an unambiguous grammar ☺). There was an erratum (errata #5200) submitted last week for this inconsistency between section 3 and 5.2: https://www.rfc-editor.org/errata/eid5200

Given this inconsistency, I think it would be valuable to discuss how we will rectify the difference in syntax as defined in section 3 and 5.2 in addition to shoring up the grammar in section 5.2.

Thanks,

Corey

From: Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> >
Date: Friday, December 15, 2017 at 2:44 PM
To: Corey Bonnell <CBonnell at trustwave.com <mailto:CBonnell at trustwave.com> >, CA/Browser Forum Validation WG List <validation at cabforum.org <mailto:validation at cabforum.org> >
Subject: RE: Ambiguous grammar for parameters in RFC 6844 (CAA)

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 <mailto: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/6a4f4213/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/6a4f4213/attachment-0001.p7s>