Re: [Sidrops] what to do when the CRL is hosed?

Rob Austein <> Mon, 23 March 2020 16:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0C243A0746 for <>; Mon, 23 Mar 2020 09:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RFn8IEXh7lUC for <>; Mon, 23 Mar 2020 09:26:41 -0700 (PDT)
Received: from ( [IPv6:2001:418:8006::30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E31E3A048D for <>; Mon, 23 Mar 2020 09:26:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Grunchweather Associates" (not verified)) by (Postfix) with ESMTPS id AF7E9139BA for <>; Mon, 23 Mar 2020 16:26:39 +0000 (UTC)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id 9B8FA2013DD7D4 for <>; Mon, 23 Mar 2020 12:26:38 -0400 (EDT)
Date: Mon, 23 Mar 2020 12:26:38 -0400
From: Rob Austein <>
In-Reply-To: <>
References: <> <> <> <> <> <>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <>
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 23 Mar 2020 16:27:05 -0000

Unsurprisingly, I agree with Steve on this, particularly:

On Wed, 26 Feb 2020 12:03:33 -0500, Stephen Kent wrote:
> There are more cases one can analyze, but I think the basic approach
> is to stick with prior, validated CRLs and contact the CA that
> issued the questionable CRL, until the matter can be resolved.

As others have observed, there is no way the RP can know what the CA
intended when the data are inconsistent.  Furthermore, given that the
code which generates the CRLs is usually right next to the code that
generates manifests (they usually advance in lock-step), there's no
particular reason to assume consistency problems would be limited to
one or the other.

Trying to make sense out of an incoherent world is always going to be
part of the RP's job.  Falling back to older valid data has always
been part of the strategy for doing that in the RPKI, and at least the
first generation of RPKI validators all did that.  It's not perfect,
but it's better than an RP trying to guess which part of the protocol
to violate in an attempt to guess what a broken CA really meant.