Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)

Rob Austein <sra@hactrn.net> Sun, 20 March 2022 19:25 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 995873A0859; Sun, 20 Mar 2022 12:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Li8aG_gpdXn4; Sun, 20 Mar 2022 12:25:40 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8D523A0854; Sun, 20 Mar 2022 12:25:39 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-100-88-186.hsd1.ma.comcast.net [73.100.88.186]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) client-signature RSA-PSS (2048 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id B8D9D4E614; Sun, 20 Mar 2022 19:25:37 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [127.0.0.1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 4AD522EA00A9; Sun, 20 Mar 2022 15:25:37 -0400 (EDT)
Date: Sun, 20 Mar 2022 15:25:37 -0400
From: Rob Austein <sra@hactrn.net>
To: Job Snijders <job@fastly.com>
Cc: Rob Austein <sra@hactrn.net>, Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, draft-ietf-sidrops-6486bis@ietf.org
In-Reply-To: <YjNIZf/GcXnjGD2y@snel>
References: <164366773060.21391.16732854790829264927@ietfa.amsl.com> <YgZTmoUhfxlsQKMJ@snel> <20220225235526.GY12881@kduck.mit.edu> <20220227002536.3516E2EA009D@minas-ithil.hactrn.net> <YjNIZf/GcXnjGD2y@snel>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20220320192537.4AD522EA00A9@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/yu0Y0WC2g8OI2_tPAfK0FARTlk0>
Subject: Re: [Sidrops] Benjamin Kaduk's Discuss on draft-ietf-sidrops-6486bis-09: (with DISCUSS and COMMENT)
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 20 Mar 2022 19:25:43 -0000

On Thu, 17 Mar 2022 10:40:37 -0400, Job Snijders wrote:
...
> > > > NEW Section 4.2.1:
> > > >    Because a "one-time-use" EE certificate is employed to verify a
> > > >    manifest, the EE certificate MUST be issued with a validity period
> > > >    that coincides with the interval from thisUpdate to nextUpdate in the
> > > >    manifest, to prevent needless growth of the CA's CRL.
...
> CA operators are free to set the Manifest's eContent nextUpdate and the
> CRLs nextUpdate as far into the future as they wish, each CA needs to
> make a trade-off about how they schedule on-call on the weekends. CA
> operators can nowadays rely on RP implementations only permitting the
> narrowest validity window transitively concluded from the entire chain.

Except that you're changing the semantics of nextUpdate from "stale"
to "hard failure", which is dangerously wrong and is not what the
semantics were intended to be by the original authors before you took
up the pen.

E pur si muove.