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

Tim Bruijnzeels <tim@nlnetlabs.nl> Wed, 13 May 2020 09:22 UTC

Return-Path: <tim@nlnetlabs.nl>
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 70AFC3A0FFD for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 02:22:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 KKj1qxIZoGBd for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 02:22: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 1D5623A0FF8 for <sidrops@ietf.org>; Wed, 13 May 2020 02:22:48 -0700 (PDT)
Received: from [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589] (unknown [IPv6:2001:981:4b52:1:bc2c:d6fa:cbdd:1589]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 2A2DC3585C; Wed, 13 May 2020 11:22:45 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1589361765; bh=JMD3qSoWJWvufS600dW3NsEPAS3VxC4hj7cyy4BcBnM=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=YF6rRqzUKPpMhtz1ynP0WFDVYGar4l/o/lRbMbH5QU8WV3b48zyxyqV3U5wMGbVsY yLbfivT1O6ydVTCXXZ0k80hvgdJCaS6561ir5iEqtobFBiSvqdLFMDdLY1QauoKP3E PlpKvz797dFIUQ/IQ4rGXZgzDfVKf09/skvq0QPM=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Date: Wed, 13 May 2020 11:22:44 +0200
Cc: sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <E4C00A94-B0AF-4FEA-8752-7630792337BA@nlnetlabs.nl>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
To: Rob Austein <sra@hactrn.net>
X-Mailer: Apple Mail (2.3608.60.0.2.5)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/rZHaVcMVZttlkcoJMv5KUGO-02A>
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, 13 May 2020 09:22:50 -0000

Hi,

> On 12 May 2020, at 23:13, Rob Austein <sra@hactrn.net> wrote:
> 
> On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
> ...
>> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
>> at the location specified in the CRLDP in the manifest’s EE
>> certificate.  If more than one .crl file appears in the manifest,
>> only file names matching the CRL specified by the CRLDP will be
>> processed. If more than one .crl entry appears in the manifest, and
>> matches the CRLDP, the first one encountered MUST be used.  Any
>> other .crl files MUST be ignored and a warning MUST be issued.
> 
> I went back and looked at how my RP code handled this.  One can very
> quickly get lost in the weeds here, but briefly: I start with a set of
> "candidate manifests" and a set of "candidate CRLs", and keep pruning
> those sets down with one form of validity check after another
> (signatures and hashes must match, timestamps must be sane, URIs must
> match, yada yada).  If, at the end of this I still have more than one
> candidate CRL, I don't necessarily pick the first CRL in the manifest:
> instead, I sort the candidates by CRL Number, thisUpdate, and time at
> which I retrieved that CRL object (in descending order of preference,
> so the timestamps only matter if CRL Number is identical, etc), and
> use this to pick the "most recent" valid CRL.
> 
> YMMV, but this arguably yields a more useful result in this screwball
> situation.  That said, this is (obviously) more complex to describe
> and to implement, so may not be worth it, given that this should never
> be happening in the first place.
> 
> If one wants a simplified version of this algorithm that stays within
> the confines of a single manifest, one could do the sort by CRL
> Number, then thisUpdate, then position in the manifest.

To the best of my knowledge there has never been any RPKI CA implementation which will use more than one .crl per manifest. So, can't we just simplify life and make sure that no one does in future?

It won't break any existing code, we just need to make it clear to new CA implementers that they should not needlessly complicate life for themselves and everybody else.

Tim