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

George Michaelson <ggm@algebras.org> Wed, 26 February 2020 00:24 UTC

Return-Path: <ggm@algebras.org>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3B373A096A for <sidrops@ietfa.amsl.com>; Tue, 25 Feb 2020 16:24:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VRWsVaoKmBxy for <sidrops@ietfa.amsl.com>; Tue, 25 Feb 2020 16:24:02 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 3F4CE3A0967 for <sidrops@ietf.org>; Tue, 25 Feb 2020 16:24:02 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id p8so794773iln.12 for <sidrops@ietf.org>; Tue, 25 Feb 2020 16:24:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UM6OfXIKUz/s1555DuAckJ3dImdpwrvVMgIGEXhsDHg=; b=gySvRNgi2D1hGoffWrrQaEpLY5NKQdfQRfBBV2hjYCFXABsT93kdLuyyFKiX5aBFWL 405xhRhHEyDONiv8MQ2MZlzCoaGyxlstKe+vI0a6lumEo0AqtdJiHbhLCszxde1ZfTlR qyBXhuQ0lZby2dmVupOMD7yj7OEFJPOTDdiXvhq05Se3N7TY3AYJtNgNCToHrVeoTCd2 kpcl0H7tOhQn8Vino03CIiAGLvUp9kJ1+SY2/49cUucDHSMf0EV/Eu6/if3y/bh2UzGp Qm261PfYe37TE3LzmWF9e1qZTc8mE+G2oCyzzRp9Gr0rdfQ1DxwdkvY62lJf06F/j9kk gRjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UM6OfXIKUz/s1555DuAckJ3dImdpwrvVMgIGEXhsDHg=; b=ObKsmQ6Opp2gN882uHdzMeiE0GfUSbZXHp6vOheJ2C+JqN+HmBR0yPjMxkvBsHoNsy pN4nEvxqzT7uv/otxKZPWKAbaDMFnrKQKtoXkRVGjQI/Fzb3FDXVPelgm75BojMB2xTi TuRzgLvRqQji7dnoS7ohQ7drEphRLeq1+9JPxfv6yy6Q5vAqPw9FKeKNGlPG9LQ9TAjH SQ2dFj1qtr5Sr4VJuxPQvXyiubTKADkrqH323mKY6igoa0csYXyUEnawk3/Du90b+wK0 D4HsHRDpzn+ONHcTEF+nvq8sgEYbc24ksoV8GhI4Wu140B0QHARlC76KyFUlFEomdyZl KIRQ==
X-Gm-Message-State: APjAAAVgyxLDbCGpHwSt17nRBCSYYaryOQ6d3jfRhK5JLUtkfIpab37+ meZsCpQ1RbxVO5Jfxi3FGXd6OpuJz9WJFxqfO8sntEPH
X-Google-Smtp-Source: APXvYqyU5l3obXpVUjeu+kSYyOnRwoMnD4RQbDPHEBIt296w4uXhssNrPEIbae+QxWDWlh3TcFRFkG6yTbtAbcVBJHk=
X-Received: by 2002:a92:5d88:: with SMTP id e8mr1409007ilg.106.1582676641326; Tue, 25 Feb 2020 16:24:01 -0800 (PST)
MIME-Version: 1.0
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net>
In-Reply-To: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net>
From: George Michaelson <ggm@algebras.org>
Date: Wed, 26 Feb 2020 10:23:50 +1000
Message-ID: <CAKr6gn2wJg1DYBOm6Ccn3ChggVB9Srhw2oEF76OZ_kLcPMsYcw@mail.gmail.com>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6bHseJeNPSsK0lebbNTDGFKVYsA>
Subject: Re: [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: Wed, 26 Feb 2020 00:24:04 -0000

I believe while I may use sloppier language, in broad intent agree
with Steve.  There is information in a CRL which is not expressed in a
manifest. We added manifests to our system, we did not deprecate or
replace CRLs.

We did not design this PKI with intent to make CRL optional or
unnecessary, and the Manifest as I understand my recollections, was to
provide a statement of what MUST be seen, not to exclude any other
things existing, or to repudiate things. it is not "complete" as I
understand it, it is only a statement of things which should not be
missing. There can be other things. it is entirely possible
publication of the manifest is asynchronous to other publication
events, (large flat repositories) and so will not reflect fetch state,
but future manifest state will.

It is a mechanism to show if intermediates are attempting to hide
things. It is not a categorical statement that other things are
invalid or valid, because they can be cryptographically valid, not
expired, but repudiated by a CRL which you are not seeing.

If you cannot see a CRL which you are told should exist, to assume the
CRL doesn't matter feels extremely unwise. I may have mistakenly
published entirely cryptographically valid things which do not now
inform my intent, and I have tried to repudiate, and you cannot see
that repudiation and now interpret states of routing in ways which do
not reflect my true intent.

-George