> On 22 Oct 2024, at 15:59, Job Snijders <[email protected]> wrote:
>
> 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.
>
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.
RSC doesn’t impose any such requirements on the filenames of signed objects.
> 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.
I don’t think it is deficient for any purpose; but it is deficient as a
building block for other protocols.
RSC as defined is fundamentally fine for cases where humans are looking at the
message - at least, it is as fine as any protocol for signing files is.
> 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
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
}
- Erin
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
