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

[Stephen Kent <[e-mail]>]

Tim,
>
>> 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.
>>
> But, redundancy also introduces more moving parts which can break, and corner conditions to check.
>
> Now it's fairly easy to get temporary inconsistencies. If CAs publish objects one by one, or in case rsync is used as a fetch mechanism (I believe that objects might change during an rsync 'session'). RRDP can resolve this, but only if CAs indeed publish their change set as a single delta.
yes, it is possible that a pub point may be updated during a sync 
operation, and thus an inconsistent set of objects will be retrieved. I 
would expect well-written RP code to detect this and try again, after a 
brief delay. For the rsynch case, one should create a new directory with 
all of the objects and then change the pub point to be the new 
directory, to make for a more "atomic" update procedure.
> But even with all that, my inner engineer would like to see as few moving parts as we safely get away with.
  if one changes to a model in which the Manifest is the sole arbiter of 
cert validity, i.e., if a cert is included in a current manifest and 
it's signature can be validated via cert path in the RPKI, the why 
bother with checking cert expiration? Same for ROAs. This is a slippery 
slope.
> Failing that I believe one agreed on way to deal with each possible corner case between MFT and CRL is needed.

How many corner cases are there?

Steve