A Profile for RPKI Signed Checklists (RSCs)
Extracted elements (28)
RSC allows a single signer to attest multiple digital objects, in contrast to RTA (Resource Tagged Attestation) which allows multiple signers to attest a single object. The single-signer profile is considered a simplification for both implementers and operators.
The fileName field in FileNameAndHash is OPTIONAL to enable 'stand-alone' usage where nameless digital objects are addressed directly through their message digest rather than through a file system abstraction, decoupling attestation from file naming conventions.
The transport mechanism for RSC files is deliberately left unspecified. The RFC gives examples including USB sticks, HTTPS-secured web interfaces, PGP-signed email, QR code T-shirts, and carrier pigeons, reflecting that RSCs are decoupled from the RPKI repository infrastructure.
ConstrainedASIdentifiers and ConstrainedIPAddrBlocks are defined to be binary-compatible with ASIdentifiers and IPAddrBlocks from RFC 3779 in their DER encoding. Implementations encountering decode errors MUST NOT ignore them; such errors MUST cause validation to fail, even if the data could be decoded under RFC 3779's more permissive rules.
When creating plain-text digital objects (ASCII, UTF-8, HTML, JavaScript, XML), converting them to a lossless compressed form (e.g., GZIP per RFC 1952) is RECOMMENDED to avoid unexpected canonicalization at intermediate systems that would cause checksum verification errors.
If no FileNameAndHash element with a matching hash is found in the RSC checkList, verification MUST fail and the error SHOULD be reported to the user. It is not an error if checkList contains more entries than the set of objects being verified, but implementations SHOULD warn the user in that case.
If the fileName field is present in a FileNameAndHash element, it MUST contain only POSIX Portable Filename Character Set characters and MUST be unique with respect to other FileNameAndHash elements that also have a fileName. If the fileName is omitted, the hash field MUST be unique among elements that also omit the fileName.
RSCs MUST NOT be distributed through the global RPKI repository system. Consequently, the Subject Information Access (SIA) extension MUST be omitted from the RSC's X.509 End-Entity (EE) certificate.
The addressFamily field in ConstrainedIPAddressFamily is a 2-octet AFI in network byte order; a third octet containing a SAFI MUST NOT be present, unlike IPAddrBlocks defined in RFC 3779. There MUST be only one instance of ConstrainedIPAddressFamily per unique AFI, and entries MUST be ordered by ascending addressFamily values.
The Certification Authority (CA) MUST only sign one RSC with each EE certificate and MUST generate a new key pair for each new RSC. This type of EE certificate is termed a 'one-time-use' EE certificate per RFC 6487 Section 3.
The digestAlgorithm field MUST specify a hashing algorithm defined in RFC 7935 (the RPKI algorithm profile). This algorithm is used to create message digests of all attested digital objects.
The resources field MUST be a subset of the set of resources listed by the EE certificate in the CMS certificates field. The EE certificate's AS identifier and IP address delegation extensions MUST NOT contain 'inherit' elements.
The version number of the RpkiSignedChecklist MUST be 0.
An RPKI Signed Checklist (RSC) is a CMS-protected content type that contains one or more checksums of arbitrary digital objects signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced it. RSCs are intended to facilitate inter-domain use cases such as BYOIP on-boarding and AS interconnection.
File verification using an RSC operates in two modes: 'filename-aware' (used when the verifier has a filesystem path) and 'filename-unaware' (used for nameless data). In filename-aware mode, exactly one matching FileNameAndHash MUST have a fileName matching the object's filename; in filename-unaware mode, exactly one match MUST have fileName omitted.
RSC validation requires performing all standard RPKI Signed Object checks from RFC 6488 (except SIA presence check), verifying eContent constraints from Section 4, and confirming that the resource identifiers in the eContent are a subset of those in the EE certificate's delegation extensions with no 'inherit' elements.
The eContentType for an RSC is id-ct-signedChecklist with OID 1.2.840.113549.1.9.16.1.48. This OID MUST appear within both the eContentType in the encapContentInfo object and the ContentType signed attribute in the signerInfo object.
IANA added the '.sig' filename extension for 'Signed Checklist' objects to the 'RPKI Repository Name Schemes' registry (RFC 6481).
IANA allocated decimal 73 (id-mod-rpkiSignedChecklist-2022) in the 'SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)' registry for the RSC ASN.1 module.
IANA allocated OID decimal 48 (id-ct-signedChecklist) in the 'SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)' registry for the RSC content type.
IANA registered the media type 'application/rpki-checklist' in the 'Media Types' registry. The type carries no active content, uses binary encoding, and has file extension '.sig'. Intended usage is COMMON.
IANA registered the RSC object in the 'RPKI Signed Objects' registry with name 'Signed Checklist', OID 1.2.840.113549.1.9.16.1.48, referencing RFC 9323.
RPKI certificates are not bound to real-world identities (per RFC 9255). RPs can only associate real-world entities to Internet Number Resources by additionally consulting an exogenous authority. RSCs communicate assertions signed with Internet Number Resources but do not convey the identity of the resource holder.
RSC data is self-asserted. Relying Parties MUST NOT make any assumptions about the signer beyond the fact that it had sufficient control of the issuing CA to create the object. The CA that issued the CA certificate has not verified the content of the RSC.
RSC objects use EE certificates but are not published in public CA repositories, creating a covert-channel risk: observers may infer the existence of RSCs from gaps in EE certificate serial numbers or from unknown serial numbers appearing on a CRL. However, such gaps do not conclusively prove RSC existence.
While a one-time-use EE certificate must only be used to sign a single RSC, CAs are not technically restricted from signing multiple RSC objects with a single key pair. Any RSC objects sharing the same EE certificate cannot be revoked individually.
FileNameAndHash is a SEQUENCE containing an optional fileName (PortableFilename, IA5String restricted to [a-zA-Z0-9._-]) and a mandatory hash (Digest). The fileName field is OPTIONAL to support 'stand-alone' mode where nameless digital objects are addressed by digest alone.
The RpkiSignedChecklist ASN.1 SEQUENCE contains: version (INTEGER DEFAULT 0), resources (ResourceBlock with optional asID and ipAddrBlocks), digestAlgorithm (DigestAlgorithmIdentifier), and checkList (SEQUENCE OF FileNameAndHash). At least one of asID or ipAddrBlocks MUST be present in ResourceBlock.