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

Job Snijders <job@ntt.net> Mon, 24 February 2020 15:15 UTC

Return-Path: <job@instituut.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C220F3A0CE1 for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 07:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id SXXbH2OdZ_DC for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 07:15:40 -0800 (PST)
Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F45D3A0CDE for <sidrops@ietf.org>; Mon, 24 Feb 2020 07:15:36 -0800 (PST)
Received: by mail-wr1-f54.google.com with SMTP id l5so6555905wrx.4 for <sidrops@ietf.org>; Mon, 24 Feb 2020 07:15:36 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition; bh=Hk2hZyCm9a0eRCwbGojXqdhV6JHpVWbdy6LG1VvlWEo=; b=L7YFiuLt9lVzYTpOGU/o9YsFcJKbm63kVOthnnoC9km9/pT+9pVFBX+VQlt9A/qnJj 0eijgPE3a7auk4/v2O3w72kx/YY6LQYrMRATVefFSruzJvGcBwMMpSAvjc47T39xqHK3 VuAZIxIHHDxtVM6iG6ATRNJ8/8306f6U3TbbIIJbUEetPVTqY9krbtMo00RiRSxe3Jit 1z1i04fCUXCPg1WnlUCPGQXcGeI2CanuraQRw1zzxzklcTIESPKMrQY2cy8QvdjJsaGU z/YH0X83gu7pw8AumfxnqOx25UqT0mI2Fr5mCJ96FAtpdq10ixml0ND+JLrAV6d75aDI +guA==
X-Gm-Message-State: APjAAAVi3hI3Qxqh/D5NJvacYcqnEtx+29GGPGAh3t5vKb/LnVMBvSTb OViAbpxtWRQP9oVwAzSUa4soyA==
X-Google-Smtp-Source: APXvYqxB3RO+u769C5j69n8xJ5R0xNc9cqycWGg5Pu+YfguD+Vt0PrOZq5k0N5z0bamKGrpSrO0CqQ==
X-Received: by 2002:a5d:4750:: with SMTP id o16mr66499765wrs.91.1582557335028; Mon, 24 Feb 2020 07:15:35 -0800 (PST)
Received: from vurt.meerval.net (vurt.meerval.net. []) by smtp.gmail.com with ESMTPSA id b13sm20578304wrq.48.2020. (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 07:15:34 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 1626d1e5; Mon, 24 Feb 2020 15:15:33 +0000 (UTC)
Date: Mon, 24 Feb 2020 15:15:32 +0000
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org, claudio@openbsd.org
Message-ID: <20200224151532.GD19221@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/tCybZO7YvXbdVm5pA7DbHEnuKEc>
Subject: [Sidrops] what to do when the CRL is hosed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Feb 2020 15:15:43 -0000

Hi group,

It seems we need guidance and consensus on what to do when the CRL is
hosed in some way or shape. We have two implementation discrepancies pop
up recently:

RIPE NCC's top level CRL expired this weekend


OpenBSD's rpki-client uses the x509 certificate validation functions
that come from libressl, which doesn't have a button to turn off only CRL
timestamp verification. I was told that some nasty code would be
required to work around that, so one can argue that rolling things by
hand in X509 handling rarely is a great idea.

One could also argue that a softer landing is needed, unavailability of
the CRL should mean that only the CRL itself is not available and
proceed to validate the tree without the revocation list. I can see how
that is helpful in some circumstances.

So, what to do? Whatever it is, ideally all validators follow a similar

Kind regards,