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

[Stephen Kent <[e-mail]>]

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