Re: [lamps] New draft: rfc6844bis

Looks like a good fix.

Please confirm results with abnfgen <http://www.quut.com/abnfgen/>.

Sean

> On Jul 18, 2018, at 12:04 PM, Corey Bonnell <CBonnell@trustwave.com> wrote:
> 
> A bit ago, Ilari Liusvaara pointed out on the ACME WG list (https://www.ietf.org/mail-archive/web/acme/current/msg02845.html) that the grammar in 6844-bis has a minor issue in regard to multiple whitespace character sequences, as the grammar produces ambiguous parses in that case. I agree with his analysis and proposed fix to the issuevalue production rule:
> 
> issuevalue = *WSP [domain *WSP] [";" *WSP [parameters *WSP]]
> 
> Thanks, 
> Corey
> 
> On 7/17/18, 6:45 PM, "Jacob Hoffman-Andrews" <jsha@eff.org> wrote:
> 
>    On 07/10/2018 06:58 AM, Corey Bonnell wrote:
>> It looks like the updated ABNF grammar for the issue property tag is missing some line breaks, as several of the production rules are now on the same line.
>    Thanks. I've fixed this in my working copy, and it will make it into the 
>    next revision.
> 
>> There is one more issue that we might want to tackle as part of the 6844-bis effort: changing the "SHOULD" for making CAA queries against authoritative nameservers to a "MUST" (section 6.3: For example, all portions of the DNS lookup process SHOULD be performed against the authoritative name server). This was originally mentioned in https://scanmail.trustwave.com/?c=4062&d=ivHO2xmUBfppFKh1daO2Kedy9FsSnsVXKPKouCUq5Q&s=5&u=https%3a%2f%2fblog%2ecloudflare%2ecom%2fcaa-of-the-wild%2f but I don't think this has been brought up on this mailing list before and thought we should at least discuss it. My opinion is that it should remain a "SHOULD" in the RFC, otherwise the RFC is dictating policy. The preferable route is to define required lookup properties in policy explicitly (eg, the Baseline Requirements would dictate that all lookups MUST be performed against an authoritative nameserver).
>    Yeah, I agree we should keep this as a SHOULD. I think defining what 
>    exactly it means could get messy. For instance, CAs are likely to use an 
>    internal recursive resolver, which in turn contacts a series of 
>    authoritative resolvers.
> 
> 
> _______________________________________________
> Spasm mailing list
> Spasm@ietf.org
> https://www.ietf.org/mailman/listinfo/spasm