Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)

Rob Austein <sra@hactrn.net> Tue, 12 May 2020 21:12 UTC

Return-Path: <sra@hactrn.net>
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 89E5B3A0BD4 for <sidrops@ietfa.amsl.com>; Tue, 12 May 2020 14:12:51 -0700 (PDT)
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 aDs9Fcu2jfqQ for <sidrops@ietfa.amsl.com>; Tue, 12 May 2020 14:12:50 -0700 (PDT)
Received: from khatovar.hactrn.net (khatovar.hactrn.net [198.180.150.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D5743A0BCF for <sidrops@ietf.org>; Tue, 12 May 2020 14:12:47 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-73-47-196-134.hsd1.ma.comcast.net [73.47.196.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (not verified)) by khatovar.hactrn.net (Postfix) with ESMTPS id C9A88139A0 for <sidrops@ietf.org>; Tue, 12 May 2020 21:12:45 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 4C2CD20156DBC4 for <sidrops@ietf.org>; Tue, 12 May 2020 17:13:14 -0400 (EDT)
Date: Tue, 12 May 2020 17:13:14 -0400
From: Rob Austein <sra@hactrn.net>
To: sidrops@ietf.org
In-Reply-To: <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net>
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=ISO-8859-7
Content-Transfer-Encoding: quoted-printable
Message-Id: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/D6Lib_lKMRIIzuq3-whlqJj5YIE>
Subject: Re: [Sidrops] rev 4 (corrected CRLDP source changes, thanks to Tim)
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: Tue, 12 May 2020 21:12:52 -0000

On Fri, 08 May 2020 11:26:22 -0400, Stephen Kent wrote:
...
> A manifest SHOULD contain exactly one CRL (.crl) file and it MUST be
> at the location specified in the CRLDP in the manifest’s EE
> certificate.  If more than one .crl file appears in the manifest,
> only file names matching the CRL specified by the CRLDP will be
> processed. If more than one .crl entry appears in the manifest, and
> matches the CRLDP, the first one encountered MUST be used.  Any
> other .crl files MUST be ignored and a warning MUST be issued.

I went back and looked at how my RP code handled this.  One can very
quickly get lost in the weeds here, but briefly: I start with a set of
"candidate manifests" and a set of "candidate CRLs", and keep pruning
those sets down with one form of validity check after another
(signatures and hashes must match, timestamps must be sane, URIs must
match, yada yada).  If, at the end of this I still have more than one
candidate CRL, I don't necessarily pick the first CRL in the manifest:
instead, I sort the candidates by CRL Number, thisUpdate, and time at
which I retrieved that CRL object (in descending order of preference,
so the timestamps only matter if CRL Number is identical, etc), and
use this to pick the "most recent" valid CRL.

YMMV, but this arguably yields a more useful result in this screwball
situation.  That said, this is (obviously) more complex to describe
and to implement, so may not be worth it, given that this should never
be happening in the first place.

If one wants a simplified version of this algorithm that stays within
the confines of a single manifest, one could do the sort by CRL
Number, then thisUpdate, then position in the manifest.

--Rob