Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

Martin,
> 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.

The overall response to a failed fetch is described in the intro to 
Section 6, as well as in 6.7. the intro states:

    If a fetch fails, it is assumed that a subsequent fetch will resolve
    problems encountered during the fetch.  Until such time as a
    successful fetch is executed, an RP SHOULD use cached data from a
    previous, successful fetch.  ...

Section 6.7 reiterates this description of what to do, and provide more 
details re what "termination of processing" means.

> 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.4 deals with acquiring all files referenced by a manifest, 
including certs and CRLs. The text says:

    The RP MUST acquire all of the files enumerated in the manifest
    (fileList) from the publication point.  This includes the CRL, each
    object containing an EE certificate issued by the CA, and any
    subordinate CA and EE certificates.

> 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?

The phrase "CA instance" is used throughout Section 6 to accommodate CA 
key or alg rollover. So, a CA instance refers to a CA cert and the 
objects issued under it, as indicated by the SIA info. This is described 
in Section 6.1, which notes to use the id-ad-rpkiManifest URI, as well 
as in the intro to Section 6.

The cached versions of objects refers to certs, CRLs, and signed objects 
that were validated during a previous fetch cycle, and which are not 
stale/expired.

> 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.
Are you positing the case where the cache contains an expired ROA for a 
CA instance, and a fetch that would have replaced the expired ROA fails? 
In that case, the cache entry for that ROA would no longer be valid, but 
I don;'t think that would affect other cache entries for the CA 
instance. Yes, this re-write of 6486 trades off robustness for more 
restrictive manifest checking.
> 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.
If a manifest points to objects that are not CRLs, certs, ROAs, etc., 
then it is in error. But, your question seems to be what processing has 
to be performed on the files contained in an apparently valid manifest, 
right? Section 6.4 and RFC 6488 defines the tests to be performed, and 
6.4 explicitly cites 6488. What additional info do you feel is needed here?
> 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?

I have not examined the RTA ID, and it's an expired draft, so ...

Steve