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

[Stephen Kent <[e-mail]>]

Tim,
> In general I agree. Which is why I mentioned the example of objects 
> one might find published outside of the context of the RPKI 
> repository, and *not* listed on a manifest. Such objects have yet to 
> be invented but theoretically one can think of signed structures under 
> an existing RPKI CA cert (e.g. using their own embedded EE) - which is 
> shared out-of-band between parties. 
That's a very forward-looking perspective, one I had not considered.
> What I am suggesting is that we *could* update 6486 and make validation more restrictive regarding manifests:
> - all objects on a manifest must be present and accounted for (I agree with Job regarding partial withhold attacks)
> - all objects on a manifest need to be validated
> - objects that are not on a manifest can be considered invalid
>
> This is in-line with the specifications defined in RFC 6481 (A Profile for Resource Certificate Repository Structure), which essentially says that all current objects must be published, and that no invalid objects may be published.
agree.
> Then, if the manifest is already a signed statement of everything that is current, at least regarding the currently defined object types, as defined in RFC 6481, then what is gained by checking that CA was also capable of generating a CRL - using the same authoritative key and publication method - that confirms that the objects that are current according to the manifest are indeed not revoked?

I agree that with strict Manifest processing, CRLs provide redundant 
info. But, by that argument, why bother checking to see if certs are 
expired, since that too is redundant in a strict Manifest processing 
scenario?

> Requiring the CRLs just feels like unnecessary brittleness to me (again in the context of RFC 6486). It creates multiple loci for bugs in CA implementations, and complicated error conditions that need to be checked by RPs. This is what I meant with the perhaps poorly chosen word 'pedantic'. Maybe I should have used the word 'redundancy'. Redundancy may seem like a good idea in general, but in this case it really only allows for the possibility of two conflicting signed messages. Thus it seems that this does not increase security, but provides more ways for things to break.

redundancy is often beneficial in security systems. it helps prevent a 
single error from having terrible consequences. But, this strategy works 
only if one is flexible when responding  to an inconsistency between 
redundant pieces of info.

Steve