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]
