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

Stephen Kent <stkent@verizon.net> Wed, 13 May 2020 13:53 UTC

Return-Path: <stkent@verizon.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 286393A0B5C for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 06:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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=-0.001, 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=verizon.net
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 YCzdBwh22WJb for <sidrops@ietfa.amsl.com>; Wed, 13 May 2020 06:53:24 -0700 (PDT)
Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 E8AE33A0B62 for <sidrops@ietf.org>; Wed, 13 May 2020 06:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1589378002; bh=Fn+58ZPG9Nq1nHCgC7YacMn+gZJTR1kNIfUoLy6gK5I=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=i4mYTr3cmeRK6cOwPhzFgeGlLQMKdQbbTsvr7aBDQItpiyAWhoCu5GWZ9MtHyXVllaXW7fh3k0v+lpsg8ULQBHyXO6zQJtToh4CjIW9rnpU9qP5oQ+DfmRn0uwoa5eeb1tsTV5BCReeFOdLAQmY15ZebCuQOVeRoMG5jAWkUl472DAUqCUeHsxNMejt2pSVjWl3sjbfFQ6nNw4rZgMrENoRn/nFuF3XcKb5epbtc0m4ePbuk7VF9WVVB/MYBjbwkZVj1Ug8XYs2dWx/wpzq5o8DrP/G6ge6Y7dt47HqvX1AUVLrtli1eaHKa5AxOlmK8t5pymWJGZKv7pLmppTFiMQ==
X-YMail-OSG: jrCbmZUVM1naJnI6pzvkIHll2MjCgtiwXJhQ.dIKtrT_79CNMuRystO70ll_mpc _YMtsXVusTbmx.M4PpLhOiqkqaS1.PYbk4G30tOn5u33mP9xkYLuE2ic.69SDwNVY_V7aQ0p3m1K XK5ZZv8E9PFEtI2L595rNAbOtDuEKVqom.AOuRJN0lKY.eUAzFbPsierQfLdXG0dqEf_oUvSb4n8 6A343yJx.Jz4VX2uQSAabIb5WCMSzch9ELTnXIoLXScJN0Mw5Y1UYGQKvEjPhl1hBQSSkQ3hsVBG ultq8AgtOOqVJX0qEpDXoofSeJqpeog7N3__DhZ9Ac4t1v6nQ_D0_rBUmCajof4x4nKxDITDRSj3 6RZAXdmDxM3XUdHBvV0HWfi7pvGEMOMnK2nPecj8yQBn94Gg0gILl7HIPrtpaa3BI4Gzg2RPTg4d v7sps2G4Ho7_S.WdYrVu22cVqWKfZaJaXrPU9BcsxYV6pEtwaKBbhUKbIPv7ZTA53aDKhtQ7FQYp 9tpUGDda4O4rq8HdYTPl2PJ0X0VGAlRpiIGPlTEyXx5G2mO1oBGgDl.WvzAsYxeJ58SJRkvnjLXn WtVejC__8EgLL8299O6eoqUyUtGIIlOTW2sjEfxZ2wNtzgJeaix16xzKojiqemvgF_gKFCLdWPp_ 93t_1Gn3AutYa4DhfLXukZCdxTf45.lY1KnQrYOV8UAEVfPWW2_Dhh7Lk56gkKnXe2ODtzr4Ydu5 AS._UiCRLgcddWDWeS3uInkUskLAxhePjDh.1eFvn76DHFsMZC5ZX1etXw0os6zSut4vOFE2AHiC i9Gz0tfJjrgpwgiUL4rS8UKKUcrBGPtNbalefm4leA2RnSx3sUTjSCFdwBnD5SeknMwAmC8s_gxY 1.NXx_lIfUhq_6EMX2JBSwnBQgKC7srKcZPs5MHfqLUrL.NRT2rTN6w9x9owZ2oRsKqcY7j619pF dlaV4Tk61POB7yr9bosuzfsZOfhqTeKCtAsP1HhHz6jZudB.kTxhFncS_ShH24GvTsqbiIk2jqJM Il_4KEMeTTRaBCt00gaNMf1EVmYRWKn3xfS5uNs.elxBcqWtntOHComnCL_Q13hgBbAhu4iTN_eH Irjp4O_.CugCE5VA6udBLG2OqW_8mk8zPUDJIvA9Cj_0Mq5T8kqaeCer2bzxFOOpdW5mxRXsyovX b32v7Ba_u6HgDjKoMyHMihydQGxzmj1PIUbsaBs5kLdLZw4GP94nIPWauxOaAdbNr4H5zfXHmFxE P9ni0mrJ3LIqOQ7L2Q60FwCHNOwJvLBA.FXi7CmR51e0R..DTtASD7Bd8jXnAs8E60u4Ny1qbKaY GAv2YVXDBhWNXHWryHXb9QRMuXMUem0zxFS7ItMkww6sATMgogZH44jbPk2dF7Kt0PDh.JFs70pV .dOuK9DzAIMbADHJwqznh1FOtam9WWiYtc8hfqbJqcAK60JKBw4jedi0N
Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 13 May 2020 13:53:22 +0000
Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID a0298c21b5fd48a9c4ce54403157cf2c; Wed, 13 May 2020 13:53:18 +0000 (UTC)
To: sidrops@ietf.org
References: <be9450ba-fe9c-465f-98a2-919772b3b32a.ref@verizon.net> <be9450ba-fe9c-465f-98a2-919772b3b32a@verizon.net> <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <73b88326-d537-93eb-b0d0-a0a82507081c@verizon.net>
Date: Wed, 13 May 2020 09:53:18 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <20200512211314.4C2CD20156DBC4@minas-ithil.hactrn.net>
Content-Type: text/plain; charset=iso-8859-7; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15904 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/7M8XRb8BNVCC2yagDBhAs0DtJtQ>
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: Wed, 13 May 2020 13:53:25 -0000

Rob,
> 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.
>
I will revise the text describing how to handle this case, based on WG 
consensus. Your approach is very robust, but also complex. Since there 
should be only one CRL in the manifest, and since Tim says that no RPKI 
CA generates more thanοΏ½ one, I tend to favor a simple requirement here, 
but ...

Steve