Re: [lamps] New draft: rfc6844bis

Sean Leonard <dev+ietf@seantek.com> Thu, 19 July 2018 13:52 UTC

Return-Path: <dev+ietf@seantek.com>
X-Original-To: spasm@ietfa.amsl.com
Delivered-To: spasm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32091130E50 for <spasm@ietfa.amsl.com>; Thu, 19 Jul 2018 06:52:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4drNsrsCcmT3 for <spasm@ietfa.amsl.com>; Thu, 19 Jul 2018 06:51:58 -0700 (PDT)
Received: from smtp-out-2.mxes.net (smtp-out-2.mxes.net [67.222.241.118]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EB6D130E0D for <spasm@ietf.org>; Thu, 19 Jul 2018 06:51:58 -0700 (PDT)
Received: from Customer-MUA (mua.mxes.net [10.0.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D152C2758D; Thu, 19 Jul 2018 09:51:56 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Sean Leonard <dev+ietf@seantek.com>
In-Reply-To: <D099A16A-68EC-4968-B038-562847B1500E@trustwave.com>
Date: Thu, 19 Jul 2018 09:51:46 -0400
Cc: Jacob Hoffman-Andrews <jsha@eff.org>, SPASM <spasm@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6736C993-99C8-465B-BD0A-DF4ABC197085@seantek.com>
References: <d25080b7-d21c-219e-8d99-7c19afb5b30f@eff.org> <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com> <171ce08e-3700-45e8-8208-08bb15077f72@eff.org> <D099A16A-68EC-4968-B038-562847B1500E@trustwave.com>
To: Corey Bonnell <CBonnell@trustwave.com>
X-Mailer: Apple Mail (2.3445.6.18)
X-Sent-To: <c3Bhc21AaWV0Zi5vcmc=>
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/PzzrAkoPO7Z-0s8o9IG4pL7V-fI>
Subject: Re: [lamps] New draft: rfc6844bis
X-BeenThere: spasm@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: "This is a venue for discussion of doing Some Pkix And SMime \(spasm\) work." <spasm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spasm>, <mailto:spasm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spasm/>
List-Post: <mailto:spasm@ietf.org>
List-Help: <mailto:spasm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spasm>, <mailto:spasm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Jul 2018 13:52:03 -0000

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