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

Martin Hoffmann <> Thu, 02 April 2020 09:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64AC93A0E95 for <>; Thu, 2 Apr 2020 02:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
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=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xY9s8d7kmPoh for <>; Thu, 2 Apr 2020 02:46:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A27E13A0E8F for <>; Thu, 2 Apr 2020 02:46:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id CE3EC2F910; Thu, 2 Apr 2020 11:46:06 +0200 (CEST)
Authentication-Results:; dmarc=none (p=none dis=none)
Authentication-Results:; spf=none
Date: Thu, 02 Apr 2020 11:46:06 +0200
From: Martin Hoffmann <>
To: George Michaelson <>
Cc: Christopher Morrow <>, SIDR Operations WG <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
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: <>
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 09:46:11 -0000

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.

Kind regards,