On Tue, Oct 22, 2024 at 01:42:46PM +0200, Erin Shepherd wrote: > In particular RSCs do not have binding of purpose (what is being > signed) or audience (who it is being signed for).
RSCs are not distributed through the global RPKI repository system, they are distributed through private channels. > 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. The fileName field is optional and it is not unconstrained: characters are constrained to [a-z], [A-Z], [0-9], '.', '_', and '-'. > 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. The CA understands exactly what it is doing: it is signing over a checksum listing with a specific set of Internet Number Resources. But on the other hand, RP should be cognizant the data in a RSC is self-asserted. The self-asserted data thusly be applied in a context that makes sense for the RP (for instance, if the nonce is as expected). Then again such caution must also be applied to data derived from signed objects that do have a purpose-specific content-type... > That perhaps requires a new RPKI content type. Sadly, this is how > things sometimes work out. It sounds like instead of using specific values in the opaque 'fileName' label field, you'd prefer to hardcode a bunch of stuff? Ultimately an RSC is a RPKI-chained signature over one or more SHA-256 hashes. If the Peering API cannot be made to work to establish inter-domain trust with such a fundamental building block, something is off. Subjectively, one might have a preference for hardcoding purposes via content-type versus using a general purpose mechanism such as RSC; but the fundamentals remain the same. > (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, …>”) Sure, a lot of things are possible. Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
