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

[Christopher Morrow <[e-mail]>]

On Thu, Apr 2, 2020 at 4:02 AM Robert Kisteleki <[e-mail]> wrote:
>
>
> >> So it is right time to reconsider the requirements posed on RP in case of “wrong” MFT.
> >
> > yes this last sentence is the discussion I'd like to see happen... I
> > think guiding that with:
> >   "Here are the ways an manifest could go badly: bad sig, bad content,
> > missing content, missing manifest..."
> >
> > and:
> >   "given the damage from X, Y, Z, the proposed actions for an RP
> > are... because ..."
>
> I was thinking along the same lines while having a related conversation
> with Job/Tim here:
>
> > I believe a more nuanced approach is needed, like if there's a problem
> > on a particular validation path (a cert is missing or has an error) then
> > invalidate that path, if a CRL is missing then warn but use a stale one,
> > but leave the otherwise unaffected bits validated.
>
> If repository R hosts objects for CAs A, B, ... Z, A has subtrees
> A1...A9 and there's a problem with the manifest of A1, the rest (B..Z)
> is perfectly fine an usable. IMO A2..A9 are fine as well. As for A1: the
> RP action IMO should really depend on what the exact issue is, for example:
> - an object is missing: check if you have it from the previous run and
> if so, use it

I would like to believe that whether a repository is 1 organization
(one repository only vaslii!)
or an organization that is hosting many repositories, the story about
CRL/MFT is the same,
at the single repository level.

In practical terms this means that RIR who host 'large numbers of
repositories for their customers'
are really just running a slew of little items. Any breakage at the
individual level is indistinguishable
from that which a self-hosted ca/repository may make. At the top of
the tree, yes there are more
possible ways to get broken, and the effect on the locally-hosted (or
self-hosted far away!)
repositories from breakage up-tree is certainly bad... but I'd rather
not get lost in that discussion.

> - a CRL is missing / corrupt / expired: warn but use the previous one
>
> I'd be happy to contribute and I think that if this happens,
> contribution from operator(s) would be extremely useful.
>

ok, I think for the upcoming interim let's see if we can have a
strawman to discuss :)