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

[Tim Bruijnzeels <[e-mail]>]

Hi,

> On 12 May 2020, at 23:13, Rob Austein <[e-mail]> wrote:
> 
> 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.

To the best of my knowledge there has never been any RPKI CA implementation which will use more than one .crl per manifest. So, can't we just simplify life and make sure that no one does in future?

It won't break any existing code, we just need to make it clear to new CA implementers that they should not needlessly complicate life for themselves and everybody else.

Tim