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

Claudio Jeker <> Thu, 02 April 2020 10:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15E1F3A089C for <>; Thu, 2 Apr 2020 03:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zg1uikyugLmX for <>; Thu, 2 Apr 2020 03:14:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7D3B3A0F09 for <>; Thu, 2 Apr 2020 03:14:25 -0700 (PDT)
Received: (qmail 68946 invoked by uid 1000); 2 Apr 2020 10:14:20 -0000
Date: Thu, 02 Apr 2020 12:14:20 +0200
From: Claudio Jeker <>
To: Martin Hoffmann <>
Cc: George Michaelson <>, Christopher Morrow <>, SIDR Operations WG <>
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
User-Agent: Mutt/1.10.1 (2018-07-13)
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: Thu, 02 Apr 2020 10:14:28 -0000

On Thu, Apr 02, 2020 at 11:46:06AM +0200, Martin Hoffmann wrote:
> George Michaelson wrote:
> > 
> > I would remind people that *all* the products in a repository are
> > signed objects. To arrive at a state where a manifest is "wrong"
> > demands two things: it doesn't reflect some real-world situation
> > regarding contents of the repository *and* its signed by keys you can
> > validate back to a trust anchor. If you cannot validate the manifest,
> > then its not "wrong" its forged, or invalid cryptographically.  To me,
> > a  "wrong" manifest checks out cryptographically but somehow is not
> > coherent with the state of the repository.
> I think we are still having this conceptually backwards: It isn’t the
> manifest that is wrong, it is the repository content. Whether it was
> originally intended that way or not, having a manifest at all to me only
> makes sense if it is considered to contain the truth, the whole truth,
> and nothing but the truth.
> I honestly believe that the current state of affairs where basically
> the guidance for RP software developers is to look at the current
> repository content, past repository content, the manifest and the CRL
> and then figure stuff out themselves is rather ... unfortunate and
> doesn’t exactly improve the confidence in the overall system.
> Given the inherent complexities of a distributed repository, it seems
> important to me to make the system as straightforward as possible to
> implement. Declaring the manifest to be the sole list of currently
> published objects is a means to this end.

I completely agree with this. As example rpki-client only looks at files
that are referenced via the .mft files. The .mft file tells the truth (it was
validated that it is the truth with the cert chain). Only files in the
MFTs will be used to build the VRP tree (and only if their hash is
correct). There is no concept of previous repository state or some other
file that is per accident around.

:wq Claudio