Re: [lamps] Fwd: [pkix] [Technical Errata Reported] RFC6844 (5200)

[Corey Bonnell <[e-mail]>]

After thinking about this further, I’m in favor of using semicolons to delimit parameters, as Tim mentioned that we likely need to continue using the semicolon to delimit the identifying domain name from the parameter list due to its current ubiquity. It would be inconsistent to use a semicolon to delimit the identifying domain name from the parameter list but also mandate that parameter name/value pairs be delimited using whitespace. That being said, I like the idea that non-significant whitespace can be used in records to improve human readability.

Given that RFC 5234 prohibits the use of implicit “linear white space” in section 3.1 (http://www.rfcreader.com/#rfc5234_line204), RFC 6844 must explicitly state in the production rules that non-significant whitespace is supported. With that in mind, I believe that the ABNF production rules in RFC 6844 section 5.1 (http://www.rfcreader.com/#rfc6844_line447) for “issuevalue” should be modified to something similar to this:

issuevalue = *WSP [domain] *WSP [";" *WSP [parameters] *WSP]
parameters = (parameter *WSP “;” *WSP parameters) / parameter
parameter = tag "=" value
tag = 1*(ALPHA / DIGIT)
value = *(%x21-3A / %x3C-7E)

(The “parameter” and “tag” production rules are unchanged but I listed them here to list the relevant rules in one place.)

Note that I removed the “space” production rule, as RFC 5234 provides us with a nearly identical (differing only in the number of allowed repetitions, but the character class is the same) “WSP” rule in its core module (http://www.rfcreader.com/#rfc5234_line520). Also note that I modified the “value” rule, as we need to exclude the semicolon (ASCII code 0x3B) from the set of allowed characters in parameter values.

Thanks,
Corey
 
Corey Bonnell
Senior Software Engineer

Trustwave | SMART SECURITY ON DEMANDwww.trustwave.com <http://www.trustwave.com/>
 
2017 Best Managed Security Service Winner – SC Media

On 12/18/17, 9:41 AM, "Spasm on behalf of Tim Hollebeek" <[e-mail] on behalf of [e-mail]> wrote:

    As pointed out on the cabf_validation list, the original text isn't just
    ambiguous, the RFC contradicts itself.  I don't feel too strongly either
    way, as long as it gets resolved soon, as property tags are about to become
    commonly deployed (there were several proposed uses discussed at the Taipei
    face-to-face meeting of the CA/Browser forum).
    
    I do however have a slight preference for only having a single separator
    (whitespace), not two in order to avoid confusion about what to do about
    whitespace after semicolons and around = signs.
    
    The semicolon doesn't really serve a useful purpose, though we do have to
    keep one since there are existing CAA records out there that use it.  I'd
    like the grammar to essentially be:
    
        domain ; [name = value]+
    
    with the clarification that whitespace is ignored.
    
    So my personal preference is the first style you mentioned, in line with the
    submitted errata:
    
        http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar bar=qux"
    
    It's the style I used in my proposal for industry standard property tag
    names on cabf_validation last week.
    
    -Tim
    
    > -----Original Message-----
    > From: Spasm [mailto:[e-mail]] On Behalf Of Jacob Hoffman-
    > Andrews
    > Sent: Friday, December 15, 2017 9:06 PM
    > To: [e-mail]
    > Subject: Re: [lamps] Fwd: [pkix] [Technical Errata Reported] RFC6844
    (5200)
    > 
    > On 12/08/2017 10:16 AM, Russ Housley wrote:
    > > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdlJPySquaA&s=5&u=http%3a%2f%2fwww%2erfc-editor%2eorg%2ferrata%2feid5200
    > 
    > The question here is whether CAA records with property tags should look
    > like:
    > 
    > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar bar=qux"
    > 
    > or:
    > 
    > http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgMZzyv9PQ&s=5&u=http%3a%2f%2fexample%2ecom IN CAA 0 issue "http://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdldOn33-ag&s=5&u=http%3a%2f%2fexample%2enet%3b foo=bar; bar=qux"
    > 
    > (note the second semicolon)
    > 
    > I think the original text is ambiguous on the point, and since property
    tags are
    > not yet widely deployed this is a somewhat free choice. I think the
    version
    > where property tags are separated by semicolons makes more sense and is
    > less error prone. It also happens to be what Hugo Landau's draft for CAA
    > Record Extensions uses:
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdlFIyn6uOA&s=5&u=https%3a%2f%2ftools%2eietf%2eorg%2fhtml%2fdraft-ietf-acme-caa-03%23page-9
    > 
    > And what was briefly implemented in Let's Encrypt's Boulder (since rolled
    > back due to a bug):
    > 
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgQUz3v8bQ&s=5&u=https%3a%2f%2fgithub%2ecom%2fletsencrypt%2fboulder%2fpull%2f3145%2ffiles%23diff-
    > 3efab53f2bcc543ac2e771ec882c57c1L310
    > 
    > So my feeling is we should reject this erratum and clarify in the other
    > direction, requiring semicolons between property tags. Thoughts?
    > 
    > _______________________________________________
    > Spasm mailing list
    > [e-mail]
    > https://scanmail.trustwave.com/?c=4062&d=gNO32sFHeluIcLm6XdmrAg7jw4lzJFuSdgofny-qPw&s=5&u=https%3a%2f%2fwww%2eietf%2eorg%2fmailman%2flistinfo%2fspasm