[Sidrops] Re: [GROW] Peering API Discovery - Use of signed checklists

[Job Snijders <[e-mail]>]

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