Re: [Sidrops] 6486bis: Failed Fetches

[George Michaelson <[e-mail]>]

Yes. This is what I mean.

The fly in the ointment is the CRL. I think we need to be very sure
about how you source a CRL which invalidates things being used to
validate a bundle. Is it acceptable to use a CRL which was applicable
when the object was constructed? I think this is weaker than requiring
the CRL to be checked for applicability at the time you validate. To
do that, you have to be online and have access to all CRL from all
Repo along the validation path.

-G


On Wed, Aug 19, 2020 at 10:29 PM Di Ma <[e-mail]> wrote:
>
> George,
>
> > 2020年8月19日 03:50，George Michaelson <[e-mail]> 写道：
> >
> > 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)
>
> Do you mean RTA validator has nothing to do with RPKI repository sync, given the RTA use-case just requires the INR holder to provide all the necessary certificates to construct the validation path down to TA?
>
> It reminds me of the similar model in RFC 6494 where the RPKI is used for IPv6 SeND.
>
> Di
>