Hi Job, > On 15 Aug 2024, at 14:39, Job Snijders <j...@fastly.com> wrote: > > On Thu, Aug 15, 2024 at 02:28:46PM +0200, Tim Bruijnzeels wrote: >> It is unclear to me how section 9.3 of draft-ramseyer-grow-peering-api >> intends to use RPKI Signed Checklists (RSC) to prove authority for an >> ASN. >> >> I think it would be beneficial to have a dedicated RPKI object for >> this instead of using RSC (even if the object is exchanged directly >> rather than published in the RPKI repository). It would remove the >> uncertainty around how this authorization works. > > RSC can be used in a challenge/response process between two parties to > verify authority over an internet resource. This is exactly what the > Peering API needs.
Sure, RSC can be used to sign an arbitrary file. So the file can be a challenge, and the RSC the response. But it’s still not clear to me what the challenge would look like. It’s entirely possible that I missed this in my glancing over draft-ramseyer-grow-peering-api, But if not then I think that defining this more clearly would be helpful. >> Furthermore, while RSC signing is easy to implement on a technical >> level, there are possible legal concerns around allowing any >> authorized user to make statements for resources outside of the >> context of routing (liability, terms and conditions, user >> authorization). Speaking as Principal Engineer / Product Owner RPKI at >> RIPE NCC I feel that dedicated objects with a clearly defined routing >> related context are much easier to understand and support in that >> regard. > > Do you think yet another OID and yet another object type will somehow > resolve any self-imagined legal concerns? :-) Self-imagined… I wish ;) The problem for the RIPE NCC hosted platform is that users are authorized in the context of the “resources” group by an “admin” user of a member or end-user organisation. They are not authorized as the “sell-my-ip”, “spread-rumors-about-my-ip”, or “random-statements-unrelated-to-but signed-with-my-ip” group, and furthermore, the RIPE NCC is no way involved in choosing what file is signed using RSC (if/when implemented), and cannot be liable for whether the signature makes any sense in the context of the observer. You understand all this, but not everyone does. So, unfortunately, there Is an assessment that needs to be made. For what it's worth I would love to implement RSC, with just some minor updates to the terms and conditions of our hosted RPKI portal, but I cannot be sure yet that this will fly. I will let you (and sidrops, and the RIPE NCC routing working group where RSC support was requested) know when we have more clarity on this. > I don't think that starting from scratch (rather than using existing & > implemented technology) would help overcome potential future legal > concerns. Well, to be clear: I did not mean to suggest that we start from scratch. Just like we have the RPKI Signed Object template RFC, RSC can also serve as a template and it would require very limited changes in implementation. I guess that I just like explicit and constrained types and don’t believe that the implementation needs to be that much more costly. Kind regards, Tim > > Kind regards, > > Job _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
