Re: [Sidrops] 6486bis: Failed Fetches

[Martin Hoffmann <[e-mail]>]

Stephen Kent wrote:
>   
> 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?

No, I am talking about a case where the ROA can be fetched successfully
and matches the manifest hash, but its EE certificate is expired.
Section 6.4 says that "if [files] fail the validity tests specified in
[RFC6488]", the fetch has failed. Thus, the expired EE certificate in
the ROA fails the complete fetch of all objects associated with the CA.

So, not replacing an expired ROA in a publication point makes the
entire CA not update anymore. I.e., any other objects that now expire
cannot be replaced until that ROA is also replaced.

You could argue “Don’t do that, then” but this approach doesn’t make
the RPKI more robust but rather makes it break more easily on simple
oversights.

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

How do you introduce new object types in this case? There will always
be relying parties that run old software that doesn’t know of them. You
rather have to assume that objects of unknown types are signed objects
with unknown content. If you do that, the current draft stipulates that
you have to read, parse, and validate them -- and then throw away the
content.

This still means that all object types added to the RPKI must be signed
objects. Whether that is okay or not, I don’t quite know.

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

I would like the document to explicitly state how to deal with object
types appearing on a manifest that a replying party does not know. If
nothing else then to make the document more helpful for implementers.

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

RTA validates signed objects distributed via alternative means using
the PKI published as part of the RPKI. I.e., one of the CA
certificates published via the RPKI has issued the EE certificate used
in that signed object.

In order to validate that object, I do not need to look at any ROAs or
GBRs, only certificates, CRLs, and manifests.

Should validation of that object fail if there is an expired ROA
published by one of the CAs along the validation chain?

Kind regards,
Martin