Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Martin Hoffmann <martin@opennetlabs.com> Fri, 15 May 2020 07:08 UTC

Return-Path: <martin@opennetlabs.com>
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 C4F0E3A07A1 for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 00:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 EtmqOrbUrcSR for <sidrops@ietfa.amsl.com>; Fri, 15 May 2020 00:08:45 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 3773F3A07A0 for <sidrops@ietf.org>; Fri, 15 May 2020 00:08:45 -0700 (PDT)
Received: from grisu.home.partim.org (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 9B03F118B4; Fri, 15 May 2020 09:08:40 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none (p=none dis=none) header.from=opennetlabs.com
Authentication-Results: dicht.nlnetlabs.nl; spf=none smtp.mailfrom=martin@opennetlabs.com
Date: Fri, 15 May 2020 09:08:40 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
Message-ID: <20200515090840.12a9464a@grisu.home.partim.org>
In-Reply-To: <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net> <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net> <m2imh0x750.wl-randy@psg.com> <076ad9b0-ea5d-47a4-52f7-8b913dc6c1ae@verizon.net> <C49A008F-02FE-4A97-9E96-5EAAFBA5AC48@nlnetlabs.nl> <156c83ba-d4d8-8baa-7f87-a2600cb9c19a@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/2Ht_AdheSIB8NY1ZWql0ve-Fbd4>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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: Fri, 15 May 2020 07:08:47 -0000

Stephen Kent wrote:
> Tim,
>
> > If not, then indeed we need to have a discussion about how to deal
> > properly with multiple CRLS. E.g. do you check *all* of them for
> > each issued certificate, or do you only check the CRL matching the
> > CRLDP of that certificate? I would also be very curious to know
> > which use case warrants having this complexity.  
> 
> My suggestion is the KISS approach - first .crl file that has a valid 
> hash is the one to use, and others are ignored. That's less forgiving 
> than what Rob accommodates, but being forgiving here might take
> pressure of a CA to do its job properly.

I’m not sure it really does. Rather, it will lead to strange looking
issues: If the wrong CRL accidentally made it onto the manifest and it
comes first, all objects are invalid even though everything sort of
looks fine. This may even come and go if a CA reorders the CRLs when
it reissues the manifest[0]. If all CRLs are referenced by objects, some
objects suddenly are invalid while others aren’t.

I think invalidating the manifest with a clear warning is the more
straightforward approach and much easier to debug.

Kind regards,
Martin

[0] That may happen if it is file system based and just adds files as
    they appear when reading the directory without sorting the file
    names first.