[Sidrops] 6486bis: Failed Fetches

[Martin Hoffmann <[e-mail]>]

Heisann,

I started to implement the rules laid out in section 6 "Relying
Party Processing of Manifests" of the draft and now have a few
questions and remarks. I decided to split these up into separate
messages. So, expect a few more messages ...

                             *   *   *

It is not quite clear how to deal with failed fetches. Section
6.4 dictates that invalid signed objects (but curiously not invalid
certificates or CRLs) fail a fetch. The consequence of this is that a
fetch already fails if a single ROA (or worse: a single ghost-buster
record) is expired.

Section 6.7 now states that I should keep using "cached versions of the
objects associated with this CA instance." What does that actually
mean? What are these objects associated with the instance? The objects
listed on the new manifest or the old manifest? Or does objects here
mean validated output generated earlier?

If indeed it means RPKI objects, then doesn’t the expired ROA
essentially block all updates to the other objects to the CA? That
would strike me as counter-productive in terms of robustness.

This rule also blocks skipping objects of types I don’t know or care
about. I will have to at least do signed object validation on them,
which means reading and parsing them and then do signature validation.
If that is intended, I think this should be called out explicitly in
the document.

But I’m not even sure it provides any benefit. I, say, I am validating
a resource tagged association (RTA, [0]), I don’t care about the ROAs
at all. Does the RTA become invalid because a CA somewhere in the
validation chain had an expired ROA?

Kind regards,
Martin

[0] https://datatracker.ietf.org/doc/draft-michaelson-rpki-rta/