Manifests for the Resource Public Key Infrastructure (RPKI)
obsoletes
- rfc-6486 — Manifests for the Resource Public Key Infrastructure (RPKI)
Extracted elements (28)
Every RPKI signed object includes the EE certificate used to verify it within the CMS wrapper (per RFC 6488), so there is no requirement to separately publish EE certificates at the CA's repository publication point. This avoids redundant publication and simplifies repository management.
Manifests are modeled on X.509 CRLs because the issues involved in detecting stale manifests and potential replay attacks are analogous to those for CRLs. The manifestNumber field is analogous to the CRLNumber field, and RFC 5280 guidance on CRLNumber values applies.
One-time-use EE certificates are mandated (changed from RFC 6486) because multiple RP implementations were found to be in a vulnerable position, possibly due to perceived ambiguity in the original specification that allowed 'sequential-use' EE certificates. The new key pair per manifest design prevents reuse-related attacks.
The manifest does not include a self-reference (its own file name and hash) because it would be impossible to compute the hash of the manifest itself prior to it being signed. The manifest's publication URL is kept stable across generation cycles because it is embedded in the SIA of issued certificates.
Although the thisUpdate and nextUpdate fields in the manifest eContent MUST match the corresponding fields in the associated CRL, RPs MUST NOT reject a manifest solely because these fields are not identical. The check is advisory, not grounds for rejection.
During CA key rollover (RFC 6489), two CA instances may simultaneously publish into the same repository publication point, resulting in multiple manifests. Each manifest describes only the objects of its associated CA instance, and manifest processing is performed separately per CA instance guided by each CA certificate's SIA.
A CA MUST sign only one manifest with each generated private key and MUST generate a new key pair for each new version of the manifest. The corresponding 'one-time-use' EE certificate MUST be revoked when the manifest is replaced.
Each RP MUST use the current manifest to control which signed object files are used for validating certificates, ROAs, and CRLs. Files NOT listed on the manifest MUST NOT be used for validation of these objects.
Each RP MUST verify that a purported new manifest contains a higher manifestNumber than previously validated manifests. If the new manifest's manifestNumber is equal to or lower, the RP SHOULD use locally cached objects.
File names in FileAndHash objects MUST consist of characters from [a-zA-Z0-9\-_], followed by a single dot and a three-letter extension that MUST be one of those in the IANA 'RPKI Repository Name Schemes' registry. CAs and RPs MUST perform filesystem operations in a case-sensitive, case-preserving manner.
If a fetch fails, the RP MUST issue a warning and SHOULD continue using cached versions of objects for the CA instance until they become stale or are replaced by a successful fetch. The RP MUST NOT try to acquire subordinate signed objects until the next scheduled fetch interval.
The EE certificate for a manifest MUST describe its Internet Number Resources (INRs) using the 'inherit' attribute rather than an explicit resource set (RFC 3779). RPs are required to verify this constraint.
The EE certificate used for a manifest MUST NOT be published in the authority's repository publication point. After signing, the private key associated with the one-time-use key pair MUST be destroyed.
The fileHashAlg field OID MUST conform to the RPKI Algorithms and Key Size Profile specification (RFC 7935). This governs which hash algorithms are acceptable for hashing files in the fileList.
The manifest and all files it references MUST reside at the same publication point. If any manifest-listed files are found at a different publication point, the RP MUST treat the fetch as failed and MUST issue a warning.
The manifest version field MUST be 0. The manifestNumber MUST be incremented by 1 for each new manifest. Manifest verifiers MUST be able to process manifestNumber values up to 20 octets; issuers MUST NOT use values longer than 20 octets.
The nextUpdate field MUST contain a time later than thisUpdate. If any published objects change, a new manifest MUST be issued. Even with no changes, a new manifest MUST be issued before the nextUpdate time.
The RP MUST acquire ALL files enumerated in the manifest fileList from the publication point. If any listed file cannot be retrieved, the fetch MUST be treated as failed.
The RP MUST check that the current time (UTC) is between thisUpdate and nextUpdate. A manifest whose current time is earlier than thisUpdate or later than nextUpdate MUST be treated as a failed fetch, and the RP proceeds to the failed-fetch procedure.
The RP MUST verify that the hash of each file acquired from the publication point matches the hash value in the manifest. A mismatch means the fetch has failed.
To validate a manifest, the RP MUST verify: (1) eContentType is id-ct-rpkiManifest, (2) rpkiManifest version is 0, and (3) thisUpdate precedes nextUpdate. An invalid manifest MUST be discarded and treated as if no manifest were present.
Upon creation of a publication point, the CA MUST create and publish both a manifest and a CRL. A CA's manifest will always contain at least one entry — the CRL issued by the CA.
A manifest is a CMS SignedData signed object with eContentType OID id-ct-rpkiManifest (1.2.840.113549.1.9.16.1.26). It contains a listing of all signed objects at a CA's repository publication point, including their file names and hash values.
IANA updated the 'RPKI Signed Objects' registry (originally from RFC 6488) to reference this document for the 'Manifest' row. IANA also updated references in the 'SMI Security for S/MIME Module Identifier' registry (id-mod-rpkiManifest, value 60) and 'SMI Security for S/MIME CMS Content Type' registry (id-ct-rpkiManifest, value 26) to point to this document.
Manifests enable RPs to detect replay attacks (substitution of stale but valid signed objects), unauthorized removal or occlusion of objects, and suppression of newer object versions. They do not repair repository corruption but allow detection of discrepancies even over insecure channels.
The manifest signing structure and nextUpdate value allow an RP to detect attempted alteration of the manifest itself. However, replay attacks within finer-grained time frames (shorter than the manifest update interval) are not necessarily detectable by the manifest structure.
RP manifest processing follows a linear chain: (6.2) acquire manifest via SIA URI → (6.3) check thisUpdate/nextUpdate time validity → (6.4) acquire all listed files → (6.5) verify file hashes → success. Any failure in steps 6.2–6.5 transitions to the failed-fetch state (6.6), where the RP falls back to cached data and suppresses subordinate object retrieval.
The manifest content is ASN.1 DER-encoded as a SEQUENCE containing: version [0] INTEGER DEFAULT 0, manifestNumber INTEGER (0..MAX), thisUpdate GeneralizedTime, nextUpdate GeneralizedTime, fileHashAlg OBJECT IDENTIFIER, and fileList SEQUENCE OF FileAndHash. Each FileAndHash is a SEQUENCE of file IA5String and hash BIT STRING.