> The RSC format has been specified in RFC 9323 I am referring to the contents of the RSC, not the RSC encoding itself.
> Whether the payload is RFC9323-compliant or RFC9323bis-compliant, the moment system B 'blindly' signs over a set of bytes they ought not to sign over from an organisational scoping perspective, B is dead in the water anyway. But this is precisely what RSCs currently allow. Without an IANA well-known registry of what different files in an RSC mean, Organisation B's CA is powerless to restrict what it signs. Solving an organisational problem (RIRs are unwilling to cooperate) by introducing cryptography problems is, as the kids say: This Ain't It, Chief. ------------------------------ 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 Wed, 23 Oct 2024 at 13:56, Job Snijders <[email protected]> wrote: > 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]
