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

[Rob Austein <[e-mail]>]

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