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

[Stephen Kent <[e-mail]>]

Martin,
> Job Snijders wrote:
>> Of course - in making strong statements like this one I can not afford
>> to assume I am right, so if you disagree - please tell me how I am
>> wrong (in detail :-) ).
> Let me counter with a different strong statement: In the context of
> RPKI, CRLs offer no additional value and can safely be ignored.
I disagree.
> The reason is the manifests. Unlike CRLs which only say "these
> certificates are not to be considered valid anymore", manifests say
> "this is the complete set of objects currently issued by this CA". They
> also refer to concrete objects, identifying them both by URI and a hash
> over their content. This is a much more powerful mechanism than CRLs.
As a co-author of the manifest document I can assure you that these 
objects are not intended as a replacement for CRLs. To provide analogous 
functionality one would have to interpret the absence of a cert from a 
Manifest as evidence that it was revoked, or expired. There is a lot of 
experience in the broader PKI community that suggests Subjects are 
sloppy about expiration dates for certs, and some evidence that CAs are 
not much better :-).
> What’s more, they offer a soft and a hard deadline for validity. Their
> next update field is a soft deadline, much like with CRLs. But there’s
> also a hard deadline in that the certificate they’ve been signed with
> expires eventually. While the former has the same ambiguity as the next
> update field of the CRL, the latter doesn’t. If the manifest is
> expired, the CA is basically gone.
I don't agree with the reasoning above. It's true that the cert used to 
verify (not sign) a Manifest will expire, but so will a CA cert. Why do 
you think that a CA will be better at maintaining a current Manifest vs. 
a current CRL? F or most RPKI CAs the trigger to generate a new Manifest 
will be the need to issue a new CRL (because many CAs have elected to 
issue CRLs on a daily basis).
> Further, the CRL is included in the manifest. So you can’t even replay
> an old CRL without also replaying the old manifest.
The discussion (in 6486) of what an RP should do when a current Manifest 
is not available, or when there are some discrepancies between what  the 
Manifest says and what has been retrieved allows for a lot of local 
policy discretion. As a result, an RP might well accept an old CRL and 
corresponding Manifest even though the Manifest appears to be stale.
> Essentially, no information conveyed by the CRL isn’t also conveyed by
> the manifest. The CRL solely serves to provide additional complexity
> for the code generating and validating RPKI objects and, apparently,
> creates ambiguity in the interpretation of the specification.

I disagree.

Steve