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

[Claudio Jeker <[e-mail]>]

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