On Tue, Oct 22, 2024 at 03:15:53PM +0200, Erin Shepherd wrote: > > 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. > > To be blunt, we have known that it is not possible to (generally) > build secure systems on such deficient primitives for over a decade > now. I first read about this in a blog post in 2015 [1] and the idea > was not new at the time. > > If you do not appropriately domain separate what you are signing, then > you - frankly - do not truly know what you are signing; as that blog > post demonstrates, it is not especially difficult to produce files > that can be validly interpreted in multiple formats. It is not a > mistake that CMS signs over the content type. > > But filenames are an abysmal medium for doing this. To avoid risk of > exploitation, the content type distinguishers should either be > allocated from an IANA managed registry, or from a collision resistant > namespace (e.g. URLs, UUIDs, OIDs, reverse-DNS, …)
RSC was modeled after RPKI Manifests (RFC 9286), specifically compare Manifest FileAndHash versus RSC FileNameAndHash. Manifests have proven to be an extremely useful component of the RPKI technology stack. In the case of Manifests the INR resources are set to 'inherit' in the end-entity certificate, in the case of RSC the resources are explicitly encoded both in the eContent payload and the end-entity cert. Manifests have an additional validity period specifier in their eContent, RSC use only the end-entity certificate's validity period. But all in all they are very alike: the issuer allows the relying party to verify whether a set of files has the checksums the issuer intended for the RP to obtain. Anything beyond beyond the scope of the RSC specification. I think your characteristization of RSC being deficient for any purpose, while also hinting that such deficiency can simply be overcome by using an OID instead of a (file)name is perhaps somewhat improvident, but alas. Your next options are: - write an internet-draft to argue for deprecation of the RSC RFC - write an internet-draft to specify how RPKI can be used to establish trust arcs between Peering API users, perhaps specifying a new object profile. - all of the above - none of the above Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
