Re: [Sidrops] 6486bis: Failed Fetches

[Stephen Kent <[e-mail]>]

George,

Thanks for the background re RTA. I think your comments address the 
issue Martin raised:

the data structure is designed to be "complete outside of a repo" and, 
unlike the other objects at a pub point, this one carries a full 
validation path to some TA, not to the CA associated with the pub point.

So, I don't think an RTA should be stored in the RPKI repo system, and 
thus it ought not appear in a manifest.

You raise the "meta-question"of whether the set of data items that can 
be stored at a pub point, and thus included on a manifest, is bounded. I 
believe that new data items might be defined for storage in the repo 
system, and that, if they are, they should be covered by the manifest. 
However, such items ought to be consistent with the overall RPKI 
functionality, not just signed objects that someone wants to piggyback 
on the RPKI repo system. Let's not encourage the RPKI to be more like an 
IRR DB.

Steve

> FYI we fully intend resubmitting RTA, we were waiting for the second
> implementation (the work Martin is doing) to have input of merit to
> spin the new version. It would be plausible to resubmit for the
> November IETF. Two running code!
>
> We designed RTA to be complete outside of a repo, so it can be used
> privately between B2B partners. Not that its things cannot "be" on the
> manifest, but that there is no dependency on the repo framework beyond
> the TA, because the passed data is the chain for validation. This
> matters to people who want to conduct activity outside of the BGP
> validation problem, which is an 'all data needed' problem. B2B uses of
> RTA are not directly about all data. Its different. (provisioning is
> typically the use case here and the intent is to show the request to
> route, originate, provision is valid, because control of the resource
> can be demonstrated. its inherently a one-to-one conversation)
>
> RTA objects have an OID, are in the registry of types. So there is a
> meta-question implicit here, that the set of OID which can be
> referenced from a Manifest is NOT bound, and CAN increase, so
> validators have to be written in a way which expect to deal with
> unknown signed things: The system is not closed, and there will be
> others in future. I think the validation of a manifest MUST NOT fail
> simply because unknown objects exist on the Manifest, especially if
> the OID lies in the arc of RPKI definitions.
>
> Martin's question is also on the other side of the deal: If a manifest
> is showing a repository is incomplete, does it cause formal
> invalidation of all things in the manifest, which has potential to
> make validation of the 'complete' chain we send in RTA not work
> because now, an object on the RTA validation path is questioned for
> other reasons.
>
> I tend to the view that only things which invalidate the certificates
> matter, ROA or other elements are not contributing to the validity of
> the RTA.  This is because they are not material to the validity of the
> object. If it was a 'whole repo' problem I could argue otherwise. It
> is not. It is inherently constrained.
>
> Specifically Missing CRL.. I have more concerns about. That would mean
> we cannot authentically deny the objects being validated.
>
> -G
>
> On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann<[e-mail]>  wrote:
>> 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
>>
>> _______________________________________________
>> Sidrops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidrops