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

Martin Hoffmann <martin@opennetlabs.com> Wed, 20 May 2020 08:15 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 83FA03A3B75 for <sidrops@ietfa.amsl.com>; Wed, 20 May 2020 01:15:50 -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 C700Fo4JzxTf for <sidrops@ietfa.amsl.com>; Wed, 20 May 2020 01:15:48 -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 3715D3A3B9D for <sidrops@ietf.org>; Wed, 20 May 2020 01:15:44 -0700 (PDT)
Received: from glaurung.nlnetlabs.nl (82-197-214-124.dsl.cambrium.nl [82.197.214.124]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 8BF76185C3; Wed, 20 May 2020 10:15:42 +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: Wed, 20 May 2020 10:15:41 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: sidrops@ietf.org
Message-ID: <20200520101541.7f8a0afb@glaurung.nlnetlabs.nl>
In-Reply-To: <97899f4b-a10e-9e78-2fc7-3984b0a155f2@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> <20200515090840.12a9464a@grisu.home.partim.org> <97899f4b-a10e-9e78-2fc7-3984b0a155f2@verizon.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.17.5 (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/YnEYR7C8KY4_Ny3KrUaoG_f1JcM>
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: Wed, 20 May 2020 08:15:59 -0000

Stephen Kent wrote:
> Martin,
> > 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.  
> 
> I'm not sure what to make of your message.
> 
> I don 't see a specific proposal here.

My apologies if this was cryptic. I just wanted to caution against
devising complicated heuristics to try and salvage a manifest with
multiple CRLs.

As I elsewhere already voiced my preference for your proposal to simply
invalidate the manifest if there are multuple CRLs, you can safely
ignore the message, though ...

Kind regards,
Martin