On Wed, Oct 23, 2024 at 01:27:29PM +0200, Joe Abley wrote: > > Independent systems can derive different expected purposes from > > context if we're not explicit about it. > > I am interested in this. > > Customers who want to do the BYOIP onboarding dance with multiple > service providers might appreciate having consistent instructions from > all concerned about what payload to sign and submit. This would also > make it easier to use a single toolchain for multiple providers. Seems > like exactly the kind of scenario where we normally expect interop to > be useful. > > I think it's a nice feature that signed checklists by design are > flexible and payload-agnostic, but perhaps there is some benefit in > specifying the format of specific documents to be used in specific > circumstances (like 'BYOIP onboarding') as well. > > Having said all of that, this is all quite new to me and I am standing > by to receive education :-)
Joe, keep in mind that - as things stand - BYOIP automation is possible because RIRs are not restricting what can be put in IRR/WHOIS "remarks:" fields; quite some cloud providers rely on this permissionless mechanism. In context of RSC: the moment a 'purpose' field (which MUST contain a name from a to-be-created IANA registry with some kind of policy) is introduced, RSC as a technology loses all its flexibility and payload-agnosticism and becomes something where both the IANA registry's policy and each individual RIR become a gatekeeper for the functionality. Earlier in the thread [1] Q Misell argued that the issuing system must know the purpose in order to understand the consequences for a given signing request; but I sense a lack of recognizition that in many cases the CA is not operated by the resource holder itself but by another entity (the RIR), and the RIRs have a mind of their own on what they do/wont support (as is evident from the growing list of RPKI-based technologies the RIRs are not supporting). What to do when an RIR chooses to refuse to sign RSC's for the purpose of "BYOIP onboarding"? Or "Geofeed"? Or "Peering API"? It'll mean RPKI cannot not be used and end-users are likely to settle for a less secure/less convenient mechanism for lack of better options. There is precedent where an RIR refused to enable certain RPSL keywords for certain classes of members (example: "geofeed:"); so it absolutely isn't far fetched that one or more RIRs would again end up in a situation where they choose not to support one purpose or another. It seems we all seem to agree on is that the introduction of a 'purpose' field in RSC is a feature for gatekeeping purposes (again, [1] explains that nicely, it helps the signer decide to sign or not). I argue against introducing such a gatekeeping knob, because the goal of RSC was to have a RPKI-based signing mechanism that can be used with arbitrary digital objects. Kind regards, Job [1]: https://mailarchive.ietf.org/arch/msg/sidrops/7uYzcRJYGTtrH8fuewup6QUID8k/ _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
