> But it’s still not clear to me what the challenge would look like. It might help to look over my attempt at defining this in my PR: https://github.com/bgp/draft-ietf-peering-api/pull/30 ------------------------------
Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574 <https://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Thu, 15 Aug 2024 at 15:19, Tim Bruijnzeels <tbruijnze...@ripe.net> wrote: > 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
