Re: [Sidrops] what to do when the CRL is hosed?

[Stephen Kent <[e-mail]>]

Tim,

Thanks for your thoughtful analysis of the options. Her are some 
additional thoughts.

In general, a stale CRL still represents the best info re revoked certs 
available to an RP, so ignoring it does not seem appropriate, to me.

In the RPKI we also have Manifests, so if a Manifest is current but the 
CRL it references is stale, then that strongly suggests that the CA has 
encountered a problem generating a new CRL, but it's still the best 
revocation status info available, so use it and consider contacting the 
CA (via the GB record) to point out this problem.

A CRL is invalid if it's signature doesn't verify, or if it has a syntax 
error, even in the face of a valid sig. In this case I would ignore the 
CRL contents, contact the CA, and keep using the freshest CRL the RP has.

Because these CRLs MUST contain sequence numbers, receipt of a valid CRL 
that appears to be current, but has an older (or the same) serial number 
relative to a previously validated CRL is suspicious. I would 
definitively contact the CA to see if it just forgot to increment this 
field properly. I probably would stick with the freshest CRL info I had 
for that CA until the matter is resolved.

There are more cases one can analyze, but I think the basic approach is 
to stick with prior, validated CRLs and contact the CA that issued the 
questionable CRL, until the matter can be resolved.

As for the considerable leeway accorded to RPs in the Manifest document, 
I concur that it allows inconsistent local behavior. If the WG can agree 
on more proscriptive language, that would be good. When we wrote 6486 we 
were unable to agree on such, as we tried to balance robustness vs. 
responses to possible active attacks on repositories or communications 
between an RP and a repository.

Steve