Re: [Sidrops] 6486bis: Failed Fetches

[Di Ma <[e-mail]>]

> 2020年8月30日 02:58，Stephen Kent <stkent=[e-mail]> 写道：
> 
> Tim,
>> Hi,
>> I agree that a correctly functioning CA will produce a sound set of objects. Also it is highly unlikely that a CA will just publish an expired ROA. The much more likely scenario is that a CA is unable to make or publish updates and the MFT and CRL go stale, and the MFT EE expires, way before any ROA or issued cert would.
> I agree that these seem to be the more likely error modes, but there also was a discussion of encountering more than one CRL, for example.
>> That being said there are scenarios beyond the control of a CA that can lead to invalid objects:
>> 
>> 1) rsync
>> 
>> If the RP does rsync only, they may get an inconsistent data set. Transactions are not supported here. They just get an old MFT and new CRL or vice versa, or they may get a new MFT but not the new object, etc. This is a race condition that happens infrequently when RPs fetch during publication. It is rare, but it does happen.
> I agree that this may happen, even if one publishes all of the objects in a new directory and the  switches the pointer. But, in that case, the RP should consider this a failed fetch and retry. I believe that's what the RPSTIR software did (does?), so it's not a fatal error.


Yes. RPSTIR2 does do so, retrying.

It is difficult for an RP to determine if it is a rollover or a mistake when it sees new MFT and old signed objects coexist in the repository in question.

If it is a mistake, RP is supposed to consider those old objects invalid as per 6486bis.

But if it is during rollover, RPSTIR2 now has to keep retrying until things are seems ok. 

IMHO, I suggest it is the CA that does make-before-break by setting up a new publication point with new MFT and new objects, keeping old ones still valid. Once the new publication is all ready to service, CA replaces old SIA with new one. This is what I can see by far a  compromise to solve this issue.

Di