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

[George Michaelson <[e-mail]>]

On Wed, Jan 13, 2021 at 4:46 AM Job Snijders <[e-mail]> wrote:
>
> On Tue, Jan 12
> Summary:
>
> * multiple people have indicated immediate use-cases for single SignerInfo

I agree. I think there is good convergence to understanding this
drive. It is easy to sell the idea of an RTA with only one EE
certificate signing its contents.

> * multiple people have voiced concerns about multiple-signerInfo

I think it is not clear why we want this. I need to try and be clear about this:

APNIC operates a set of subsidiary CA under our trust anchor which
follow the path of entry of INR into our duty of care. So, for our
members in particular, it is not unusual to want to make assertions
about "all my holdings" which innately demand more than one CA be
brought into play. This is not multiple signing entities, it is one
entity, controlling a set of EE certificates which are neccessary to
make the signing assertion over the list of INR related to the
context.

It is true that when we designed RTA we did design it to encompass
discretely different entities (people) sending a cryptographically
verifiable statement of intent or meaning which bound them together
mutually. So, we still see utility in this, but I understand how
people in routing contexts don't see that right now. But, the thing is
we are not looking to solve only routing-active (BGP) problems in
RPKI: we are looking to provisioning and other contexts, where it
would be logistically hard to have to deal with a number of discrete
parts to be assembled to make the assertion, compared to being able to
use one: An example here is the JSON submission path in BYOIP, which
really expects a singleton to be passed in.  in APNIC, neccessarily,
this is a set of EE signing.

> * I've expressed a willingness to facilitate a single SignerInfo
>   implementation, but I'm not willing to implement or support multiple
>   SignerInfo.

Job I think this is an unhelpful assertion. Of course you own your own
code, but choosing to ignore work which is well formed, ASN1 and is
capable of being multiple signing EE certificates is I think wrong.

We have two valid inter-operable multiple signing implementations already.

If you could reconsider, and at the very least demonstate that you can
manage a singly signed instance, but inside the wrapper in ASN.1 which
is innately capable of being multiply signed, I think it is very
likely this will permit well formed, singly signed things to become
normal inside this form of CMS which can be used by other people to
say things which demand multiple signings.

I can easily conceive of things in ASPA  or customer-cone which could
benefit from tying somebody else's AS and the IP, which innately
demand both partys signal intent. You just said you are not willing to
think about implementing improvements to routing security which could
leverage that.

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

I very much hope you re-consider, and understand why we have chosen to
retain multiple signing capability in the CMS wrapper: We see a lot of
problems with demanding asset holders go into multiple, discrete,
unrelated assertions to declare intent over the whole of their
holdings, and we think this is a situation which is very likely to
become more common, especially as people become bound into inheritance
of INR which lie in different regions, but one ASNs assertion of
routing.

Russ Housely has been kind enough to act as an ASN.1 "expert" and
reviewed our logic, and made some changes in the formalisms of how we
declare the ASN.1 for the CMS, but without changing the on-the-wire
encoding. I have included this in the 00 revision, posted to the WG
under the WG name.

cheers

-George