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

Stephen Kent <> Tue, 24 March 2020 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BD873A0C04 for <>; Tue, 24 Mar 2020 08:38:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.563
X-Spam-Status: No, score=-3.563 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, RCVD_IN_MSPIKE_H2=-1.463, SPF_HELO_NONE=0.001, SPF_PASS=-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 L3w2TOkfCtj6 for <>; Tue, 24 Mar 2020 08:38:22 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C4EBB3A0BDE for <>; Tue, 24 Mar 2020 08:38:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1585064300; bh=Fg86v8sRy9ntKDRW9e/U3Gx1Jo90nRVTE8JXA50sr+c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=efE30TX52EYTXMiHHgLonl+ucAUkfREGD74QxGWszivM+DR5UWYGoSWbV50YLcS1JEcxb+I7mUA6R2YW4pyDq910NGg/mMZqZLqDdUNE5NuvBo5d6M7spamuURjURfTqw9omwJ6nHOlPbuH1/Fl/7j/+obe0zNRQy7OqwOzD7H5pZtZwOWBn3iDGjna0Ulc/QXCkhFLBI52/wwHqdrzIhsR2iq22wXaXei4cJlKaJyCw+B7chCvx0jQoK8aU98MMWpRbV0fgbyUwzxUKpJYi2kDDPvfRtnQsqB5wxs762oGDOkss5Q1qSrHyu3Cvjgf9iZbd0+roRih8dnwqVdznjw==
X-YMail-OSG: RPlqmw4VM1nOgL3kr1P5vzFf87pszgpMiEEnqfp1Ua4ZBsWPJ9cI8pBh4nLicOC n2930COyFMMxUEyxFgcQfq2d.AxGEH95FdffjC_jBb2eheZM2xMXkn3QWxmMGb8tL6l_hfwxQdd0 u5CCse8dS7yBoxGKaXhf7WYwZyzq4nSRxbboEy_Z0lBDfhF.hJAerjE3BurHqQ.gb3JYuNx7LOcT VN7rjrKTxHxpi0cS3AkFlsicVt44Wkg0lFQtH6FWEGqtEJ.tTN0fzo8v0jnWzok8.jX6RbVbm_jb vuCmCDeCxHHJT0cMLbzULnwaRqLSdI3e2jp.dO7QFAFPY7Apd7y5sGhdTGWY4uOzPAjJNT9K17iO .JYT6ZGgYItYa0eu00G8Wulwiza6ylWhpLXfYJhZgNUFdZdYhW0xhVnEzUE2SVaJlb4Qgec31LC_ Cthv6aRKW2jwBZH_HmIi5zmtfuJJ.mfjuiDqe49t18BrKvpQXtWhp1U138.oLaOqI3h.OZe_Co25 j.MbwS8w1z3V6GA9VsnBjUjlC8oz9JqOyc3dHbmA2oQad7ZD_xY7miYnFjS0C3qFcT7DMmOTY0vg Tkt5milznfDh7TN9z6DwliesrjIMKD7DYDAH_hoUGjYLCvIco1elLOF5DLsm6KGextFX1PG8ILlX C1d1aiuDlbsUVw5xcTTIN_7odDGx6SesbhexVvjGrtZkupM0a7tTUWUSZ4M2PI1p6Mu3wAJRL_uG u6miyA1LJzZqN8A3gk.D356rxfOvUHWYBsGsJCaqFSrqLbANYNe2EdDvvlb47rx0fq0cn3o5GVG0 AWnr4TvibJqwxryZ8zQp0r9q_EQfayFBL35xTSoQIpB3IrA60fYkuPdKctjALwYfY6PTMV9JzOwy 1UW5NVvkPcseXBhFhBgHJ6RpX5wX3nLiLkyrrzZv4u6BIObKj6q.1jAtM01Yy1KRhfvioVx7ImjI MwiW_hjjANIF4zab1mkzmXpwfYGnLc8C8wWGb_6QozSCYNmCzkKv255TgvrflyCvqt7Q_fesdGxP 1aKAc5U7SCPkBqLu763VoWF0zkbzpIyxOkeroaAiGKki8PDYl2Anu9vlaQ__lY3OjTzDN9Ln6ojW bwjsbrheWtCLn75.MUAL_.0qaf.jf5eu6zXO8ALHwBK4WNAGvC7Zqv8IrEAUjCntKFqfABO0ZtjH PLZpVbvY..5ucx9lBN9JVDbphDxn1JuB3Wg5MZjxNpycHnplTsGV2889bZKfTIkPzxXc7s_fbwc_ IueYnmwCUAY5GPKHD2dZfxn.3UmU5He2j8O0yHmk1yPJm_OErTNMXOEqAbdzPSTw5cJkd0RfF.3u hbEE2VF6zUBXY7InbU3cFLJi43TZ67Y_at7hl3ZBXXh8NJwp_0Nn_8HbZlTLidpgIs8cAuuP0Is_ TSuYPiWvlW3FYFL1CqCaRVJlJTiDOgw--
Received: from by with HTTP; Tue, 24 Mar 2020 15:38:20 +0000
Received: by (Oath Hermes SMTP Server) with ESMTPA ID 98143ce3d8f924c6fb805513f9023641; Tue, 24 Mar 2020 15:38:18 +0000 (UTC)
To: Tim Bruijnzeels <>
Cc: SIDR Operations WG <>
References: <> <> <> <> <> <> <> <> <>
From: Stephen Kent <>
Message-ID: <>
Date: Tue, 24 Mar 2020 11:38:17 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15518 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_242)
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: Tue, 24 Mar 2020 15:38:40 -0000

>> redundancy is often beneficial in security systems. it helps prevent a single error from having terrible consequences. But, this strategy works only if one is flexible when responding  to an inconsistency between redundant pieces of info.
> But, redundancy also introduces more moving parts which can break, and corner conditions to check.
> Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta.
yes, it is possible that a pub point may be updated during a sync 
operation, and thus an inconsistent set of objects will be retrieved. I 
would expect well-written RP code to detect this and try again, after a 
brief delay. For the rsynch case, one should create a new directory with 
all of the objects and then change the pub point to be the new 
directory, to make for a more "atomic" update procedure.
> But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.
  if one changes to a model in which the Manifest is the sole arbiter of 
cert validity, i.e., if a cert is included in a current manifest and 
it's signature can be validated via cert path in the RPKI, the why 
bother with checking cert expiration? Same for ROAs. This is a slippery 
> Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed.

How many corner cases are there?