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

[Ben Maddison <[e-mail]>]

Hi Tim, all,

Happy new year... hopefully :-)

On 01/11, Tim Bruijnzeels wrote:
> Dear all,
> 
> <snip/>
>
> - Multi-sign: Complexity for RPs
> 
> (note, I will use an informal description here)
> 
> For single signed the RP needs to verify that all resources on the RTA are contained by the EE certificate, which is validly signed all the way back up to a known TA. The RTA MAY include CAs and CRLs needed for this verification. If they are, and if the CRLs are not stale, they will be used for validation. If they are not present, stale or invalid, then the RP can look at the public RPKI and find CA certificates and CRLs there.
> 
> For multi signed the process is not changed much. But rather than doing this once, the RP will need to do this N times *and* it will need to verify that the union of resources in the EE certificates used for signing include the described resources.
> 
This was kinda the point I was making when I said that I couldn't think
of any use-cases for which multiple RTAs wouldn't work:

The above logic works just the same if you instead have N RTAs over the
same signed data, and require that the union of `resources` from each be
the same as the set described in the signed data.

Doing it this way seems to present the advantage of decoupling the
rpki-validation of the CMS blob from the application-specific-validation
of the underlying data.

Every use case for this will require tooling to perform additional
validation of the signed data against the RTA (at least verifying the
digest, probably more), so this doesn't introduce a new step in the
process, it just moves responsibility for it out of the RTA spec.

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

Cheers,

Ben