Re: [lamps] New draft: rfc6844bis
Jacob Hoffman-Andrews <jsha@eff.org> Tue, 17 July 2018 22:45 UTC
Return-Path: <jsha@eff.org>
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 B59C7130F1D for <spasm@ietfa.amsl.com>; Tue, 17 Jul 2018 15:45:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Level:
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 iolZDcHSJyTk for <spasm@ietfa.amsl.com>; Tue, 17 Jul 2018 15:45:29 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B217130DF4 for <spasm@ietf.org>; Tue, 17 Jul 2018 15:45:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=qSCfzx7vncWWjAg3iVXz/KfZGRpYcKoA7SLNz4FSAZo=; b=HMdPKSOHpfq82DziPPP5Ix3iPX fPK3EFQpm6ajI+InrddTiCoXesm3FZsiplrO7F0s7vWfC1KRYPnUzQtvIzHddGGAYzsG2diXP+ggF eG6SW9kvLTbXSf9Z2IaJgW6FEQhoRxCPfca9Upk1SIx1imOXC6hp7eAhJYwmjgmx0voE=;
Received: ; Tue, 17 Jul 2018 15:45:28 -0700
To: Corey Bonnell <CBonnell@trustwave.com>, SPASM <spasm@ietf.org>
References: <d25080b7-d21c-219e-8d99-7c19afb5b30f@eff.org> <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
Message-ID: <171ce08e-3700-45e8-8208-08bb15077f72@eff.org>
Date: Tue, 17 Jul 2018 15:45:28 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <0EA657BD-8E44-4173-8059-8A312998DAA4@trustwave.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/spasm/olbJ2UfaTCnJcuKL9RlNsKTQOuU>
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: Tue, 17 Jul 2018 22:45:32 -0000
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://blog.cloudflare.com/caa-of-the-wild/, 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.
- Re: [lamps] New draft: rfc6844bis Corey Bonnell
- [lamps] New draft: rfc6844bis Jacob Hoffman-Andrews
- Re: [lamps] New draft: rfc6844bis Quirin Scheitle
- Re: [lamps] New draft: rfc6844bis Ryan Sleevi
- Re: [lamps] New draft: rfc6844bis Quirin Scheitle
- Re: [lamps] New draft: rfc6844bis Ryan Sleevi
- Re: [lamps] New draft: rfc6844bis Jacob Hoffman-Andrews
- Re: [lamps] New draft: rfc6844bis Corey Bonnell
- Re: [lamps] New draft: rfc6844bis Sean Leonard