Re: [Sidrops] proposed, revised text for Section 6

[Tim Bruijnzeels <[e-mail]>]

Hi Steve, all,

> On 5 May 2020, at 22:09, Stephen Kent <stkent=[e-mail]> wrote:
> 
>>> 6.5. Mismatch between Manifest and Publication Point
>>> 
>>> If there exist valid signed objects associated with a CA instance and
>>> they do not appear in any current, valid manifest for this CA
>>> instance, these objects MUST be ignored by an RP, and a warning MUST
>>> be issued.
>> Are we sure about the above? The above approach would preclude us from
>> using the current valid manifest to determine which .roa files should be
>> deleted from the local system, right?
> I'm not an implementer, but can't one delete cached roa files based on them not appearing in the current, valid manifest?

We may be intending the same thing here. Generally speaking I am in favour of not deleting any objects because of rsync --delete, or updates / withdraws in RRDP only. So add things only, and delete them when you have seen a signed statement that the objects are no longer relevant.

The repository server is essentially untrusted by the RP, or should be! Definitely when using rsync, but RRDP with self-signed HTTPS is also highly questionable. Changing RRDP to say that TLS Verification MUST be done can help a bit, but even then there are issues with web TAs, and it could be that the repository server itself is compromised.

But details around this can be complicated. I don't think that we can specify one way to do deal with this that will be acceptable to all RP implementation. There is more than one way to do it, and therefore it may be better to specify the boundaries of what an RP MAY or MAY NOT do regarding caching.

I think the following consideration should be kept in mind:

1) stale/expired mft

Do NOT just delete things because the CA did not issue / you did not see a new current MFT. Only delete if you see a new current MFT that confirms that something is no longer relevant.

2) poisoning

Be careful if you rely on the SHA256 hashes only. I could include your object on my MFT and then remove it in an update. This should not remove your object from the cache.

3) key rolls

New keys may publish updated delegated .cer files under the same name. Be careful when just relying on the URIs.

4) require confirmation: rsync delete / RRDP update/withdraw?

If delegated .cer files are removed, should their content also be removed? Maybe. But what if this is a temporary issue at the parent? The child would not typically re-publish things. You will not see a new delta.

There is something to be said for deleting objects only if they are removed at the repository *AND* they are actively removed by a new manifest.

I have some ideas about how I would make this work if I were to implement something, but I do not presume that that would be the only or best way.

Note that different implementations regarding this will lead to differences in the availability of cached objects. But they would not lead to different validation outcomes based on the same set of objects.


Tim