> Automation systems would never receive a RSC without first having sent out instructions about what's expected in the RSC's payload.
Whilst this is on the surface correct, it misses the point. Consider the following: 1. System A expects an RSC in format A 2. System B is unaware of format A, and is thus unaware of the consequences of signing an RSC in format A 3. User A asks System B to create an RSC in format A 4. System B happily obliges, not knowing the consequences of what it is signing 5. System A accepts the RSC from User A - even if User did not have the required permissions within the organisational scope of System B to do so > I suspect purpose can be derived from context in which the RSCs are sent/received. Independent systems can derive different expected purposes from context if we're not explicit about it. ------------------------------ 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 Tue, 22 Oct 2024 at 20:56, Job Snijders <[email protected]> wrote: > On Tue, Oct 22, 2024 at 04:28:17PM +0200, Erin Shepherd wrote: > > The key difference between RPKI manifests and RSC FileNameAndHash is > > the following paragraph from RFC 9286 4.2.2: > > > > > Names that appear in the fileList MUST consist of one or more > > > characters chosen from the set a-z, A-Z, 0-9, - (HYPHEN), or > > > _ (UNDERSCORE), followed by a single . (DOT), followed by a three- > > > letter extension. The extension MUST be one of those enumerated in > > > the "RPKI Repository Name Schemes" registry maintained by IANA > > > [IANA-NAMING]. > > > > Combined with the requirements specified in RFC 6481, the objects are > > all typed by their filename extension. > > I am not sure typing is what brings security in this aspect of the > context. The Manifest processing code won't care whether it is a valid > or invalidly encoded ROA, or GBR, or something else that happens to have > .roa as extension. Manifest processors on the RP side have to ignore > extensions they don't recognize anyway, because otherwise innovation > would be stiffled (e.g. otherwise CAs publishing new stuff like .asa > wouldn't be possible until all RPs support it). > > > RSC doesn’t impose any such requirements on the filenames of signed > > objects. > > Correct, because RSC is used as part of private exchanges where both > parties know what they want: both parties can challenge each other to > sign a nonce they associate with the current business process at hand, > or sign a hash over a public key that's exchanged; both sides can > challenge each other to overcome insecure channels. It is a signature > over a listing of one or more arbitrary digital objects. Both sides need > to know a-priori what they want out of the exchange of RSC objects. > Automation systems would never receive a RSC without first having sent > out instructions about what's expected in the RSC's payload. > > > I don’t necessarily even think there is (necessarily) a need to > > introduce a new ContentType. One could perhaps imagine amending the > > definition of RpkiSignedChecklist to > > > > RpkiSignedChecklist ::= SEQUENCE { > > version [0] INTEGER DEFAULT 0, > > resources ResourceBlock, > > digestAlgorithm DigestAlgorithmIdentifier, > > purpose [1] IA5String OPTIONAL, -- version must be 1; value > registered within (new IANA registry) > > checkList SEQUENCE (SIZE(1..MAX)) OF FileNameAndHash > > } > > One of my fears is that introducing such a field will put the RIRs in a > position to cherrypick (restrict) which purpose they'll allow their > 'hosted' systems to sign or not. > > For example, an RIR might elect to only emit objects with purpose > "peering-api-auth", and refuse to emit purposeless RSC objects, or > refuse to add (some) new entries from the 'new IANA registry'. I see a > potential for reduction of ability to do permissionless innovation, > becaues two new gatekeeper layers are introduced: IANA & each RIR. > > Then again, 2 years after publication of RFC 9323, none of the RIRs > support RSC anyway. > > An example that comes to mind is how for a long time the optional RPSL > "geofeed:" attribute in some RIRs IRRDBs was not allowed for some types > of space, so resource holders had to resort to putting a "geofeed:" > attribute inside a "remarks:" field. Without the opaque 'remarks:' field > it probably would've been more challenging to get Geofeed referencing via > inetnum's off the ground. Whether that's a good or a bad thing I don't > know. > > To summarize, it seems you argue that purpose must be encoded in the > signed payload, and I suspect purpose can be derived from context in > which the RSCs are sent/received. > > Kind regards, > > Job >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
