On Wed, Oct 23, 2024 at 03:30:55PM +0200, Q Misell wrote: > > The RSC format has been specified in RFC 9323 > > I am referring to the contents of the RSC, not the RSC encoding itself.
The content of the RSC is an optional character-restricted label and an OCTET STRING of type "Digest", which MUST be SHA-256. > > 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. Following this line of reasoning, I am skeptical an IANA registry will help impose the safeguards you are looking for. Misuse within the specified context can still occur. > Solving an organisational problem (RIRs are unwilling to cooperate) by > introducing cryptography problems is, as the kids say: This Ain't It, > Chief. I think it is helpful to be mindful of what various stakeholders might or might not be willing to implement, otherwise we continue to be stuck using IRR "remarks:" fields. As the kids say, perfect is the enemy of good. To be clear, we are not discussing a cryptanalytic problem, right? Kind regards, Job _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
