> On 15 Aug 2024, at 14:39, Job Snijders <[email protected]> wrote: > > On Thu, Aug 15, 2024 at 02:28:46PM +0200, Tim Bruijnzeels wrote: >> 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? :-) > > I don't think that starting from scratch (rather than using existing & > implemented technology) would help overcome potential future legal > concerns.
I cannot speak to the legal concerns here - that is clearly Tim’s area of expertise - but looking over Q’s draft[1] of implementing RSC for OAuth support, I think it very quickly becomes evident that RSC are technically deficient for non-human-to-human use (i.e. for any use case other than a human signing a PDF of text file or similar intended to be consumed by another human) In particular RSCs do not have binding of purpose (what is being signed) or audience (who it is being signed for). The latest version of the MR attempts to hack around this by requiring the use of two named files, one of which contains the peering API base URL. In 2024 we should not be designing cryptographic protocols whose security properties rely upon magic filenames in otherwise unconstrained fields. I strongly believe that, to do this to the security standards we should be expecting of modern-day Machine-to-Machine IETF protocols requires a system whereby my RPKI CA understands what I’m asking it to sign. That perhaps requires a new RPKI content type. Sadly, this is how things sometimes work out. (The exact form of this is of course something that would need to be worked out. The OAuth ecosystem would probably prefer a JWT signed by an RPKI-chained end entity certificate. Perhaps the request itself could also be signed and so could encode “Authenticate to <the peering API> at <https://….> for <AS12345, AS23456, …>”) - Erin [1] https://github.com/bgp/draft-ietf-peering-api/pull/30 _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
