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

Christopher Morrow <> Thu, 02 April 2020 14:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 492AE3A1337 for <>; Thu, 2 Apr 2020 07:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DWleKuWgtfvB for <>; Thu, 2 Apr 2020 07:18:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E16DD3A1326 for <>; Thu, 2 Apr 2020 07:18:58 -0700 (PDT)
Received: by with SMTP id n1so1715013qvz.4 for <>; Thu, 02 Apr 2020 07:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=4HnLPwxmm34eZKzEs/5mNzw8WW57rouqk8RUY3nB5ac=; b=a5MlnJ9YUZiuZtJ2hh/7IByXoDtBwda5Fo//dfARQ8b1FpCIri6CnQK9yWRcIbemLg XlKgrFKe/hIT0oGnOqByoYY7Tbl7ONkyQSx7wEDr0j4DjE5p2JEOcSc3283c06MdyraY UFuH5+xNcFaW685DsYZoEGtADqBRymqEShE8CKJCUvRuqZbEjUnzxCfloNULqNai/HL6 ZI+koGgU84YVTAMVmCKGgqJleV6HKnutAJO6NejJ6nRqcgwsbET4q2JBTMYV03IxiVtA 6qG+AllaBWrI+vwoAq+09laKqIvyGRK4/UvTRYxqV2+O3YONYpGXp41d6Iwy3+H+TZK8 TsnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=4HnLPwxmm34eZKzEs/5mNzw8WW57rouqk8RUY3nB5ac=; b=mUvPwgiDPRrVJLl5y3xCjqGFu+8MpnXDOcFqP/stwoa16SZvtOcYQkphOH74pLgH2T Y3QhhZ23LnJOVriip/8TnVVN0TC7QvO9W9LBbCldV/GxaMxQgPs9hk0CuKz9C7grVX/L EWhRXMX8Fc8a1ZQMqSRgjLVvuhkmWsTaVqiFlR3RPpDrO9F3JjqiCdOAToZULQbZvWtS MbpEcXMgpTCzhTWIjcaD6McRC8i1YpBg2TG87fdoyta5M6OT6qK4y9zngJt8/kdfQ0J4 hTc93VK4l/GZIiNrSrvQFs2QqkdumkIQ8WjFVpuKyrRtq6Ea5EFo5J+9g94XLs2AYusb XPZw==
X-Gm-Message-State: AGi0PuadvkHFJCLc2/I5PfXtXgRyE8bhVm6cw4Nwmi00BVukYtiHpcrf fg65qT9bWWTWi21iyLZ4qWJlQZEH4VytU5VFOjE=
X-Google-Smtp-Source: APiQypI+/0+eFzpqoNhYLNUhrPtEjf55JjG1TJctAkdVqSrlp/51RCNbT4P+vxMaLLHFd7OoUiYAPVQTRh/205MzV00=
X-Received: by 2002:a0c:aee5:: with SMTP id n37mr3266680qvd.173.1585837137606; Thu, 02 Apr 2020 07:18:57 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Christopher Morrow <>
Date: Thu, 02 Apr 2020 10:18:46 -0400
Message-ID: <>
To: Robert Kisteleki <>
Cc: SIDR Operations WG <>
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 14:19:01 -0000

On Thu, Apr 2, 2020 at 4:02 AM Robert Kisteleki <> 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 :)