Re: [Sidrops] feedback on draft-michaelson-rpki-rta

[Job Snijders <[e-mail]>]

On Tue, Jan 12, 2021 at 04:58:00PM +0200, Ben Maddison wrote:
> > If N == 1 then this does not increase the complexity. If N > 1 then
> > there may be some fragility, because any of the paths can fail, but
> > it is reasonable to state that if multiple signatures are required
> > then it is a requirement that the RTA MUST be considered invalid if
> > the validation of any signature or EE certificate fails.
> 
> It arguably also adds flexibility, in that the consequences of having
> an incomplete set can be application-specific. In some cases, a
> partial set may be useful, in others it may render all the RTAs
> useless.
> 
> When I started writing this email, I was mostly agnostic other than
> insofar as this may speed-up or delay implementation.
> 
> Having thought about it, I actually think the multiple RTAs pattern is
> better than the multiple signer pattern.

1/
We should be cognizant Relying Parties might not have all applicable
Trust Anchors in common with each other. Lacking a single common Trust
Anchors will invalidate the entire multiple-SignerInfo RTA.
Troubleshooting such cases in a multiple-SignerInfo will be harder
compared to each RTA object containing a single SignerInfo (and thus is
bound to a single Trust Anchor).

2/
The complexity of Multiple-SignerInfo in a Multiple-Trust Anchors
context is further compounded when one takes into consideration any
additional variances resulting from different X509 Certificate Policies
(RFC 6487 & RFC 8360) on different validation paths towards a single
multiple-SignerInfo RTA. 

3/
I think SIDROPS needs to take a hard look at whether significant
increases of complexity are a wise move at this phase of global RPKI
deployment. 'Mixing' of Trust Anchor trees at this 'pre-validation
stage' is a big unknown for the working group, it has not been done
before. Contrary to Martin's comment "The work of dealing with resources
under multiple parents has to be done." ... that's just not true,
this is not work that *has* to be done, it is entirely avoidable.

Given how much problems some validator implementers had in 2020 (and
still have!) to just get manifest & CRL basics right, makes me very
skeptical about the group's ability to now suddenly perform at a much
more advanced level.

4/
Last but not least: if we follow a single-SignerInfo model, all the
RIRs/NIRs should be able to fairly easy to implement a web tool for:

    'copy+paste attested object's hash here -> click which resource should sign -> download resulting RTA'.

Implementing single-SignerInfo RTA at the RIR-hosted CA level can
be straight forward, as such hosted services only needs to concern
themselves with a single Trust Anchor (themselves) and there won't be
passing around of RTAs for co-signing. The RIR-hosted portal also
doesn't need to see the actual digital object being attested, just the
hash. I fear multiple-signerinfo RTA would see lack of adoption in that
part of the ecosystem, and "just use krill" is not the answer.

Summary:

* multiple people have indicated immediate use-cases for single SignerInfo
* multiple people have voiced concerns about multiple-signerInfo
* I've expressed a willingness to facilitate a single SignerInfo
  implementation, but I'm not willing to implement or support multiple
  SignerInfo.

I hope the authors reconsider so we can get down to the business of
deploying RTA! :-)

Kind regards,

Job