Manifests for the Resource Public Key Infrastructure (RPKI)
obsoleted by
- rfc-9286 — Manifests for the Resource Public Key Infrastructure (RPKI)
Extracted elements (24)
Manifests are modeled on X.509 CRLs because the threat models are analogous: detecting stale data and replay attacks. The manifest payload syntax differs from CRLs because RPKI repositories contain signed objects (e.g., ROAs) not covered by CRLs.
The manifest does not include a self-reference (its own filename and hash) because it is impossible to compute the hash of the manifest before it is signed. This is an inherent limitation acknowledged in the generation procedure.
When a CA performs a key rollover and two CA instances simultaneously publish to the same repository publication point, each CA instance publishes its own manifest describing only its own products. There will thus be multiple current manifests at the publication point.
A new manifest MUST be issued and published on or before the nextUpdate time. Additionally, a new manifest MUST NOT invalidate the manifest object URL of previously issued certificates, so the publication name (object URL) MUST remain unchanged across manifest generation cycles.
For a 'one-time-use' EE certificate, the validity period MUST exactly match the thisUpdate and nextUpdate times of the manifest. For a 'sequential-use' EE certificate, the validity period MUST encompass the full thisUpdate-to-nextUpdate interval.
If a manifest encompasses a CRL, the manifest's nextUpdate field MUST match the CRL's nextUpdate field, as the manifest will be re-issued when a new CRL is published.
Manifest verifiers MUST be able to handle manifestNumber values up to 20 octets. Conforming manifest issuers MUST NOT use number values longer than 20 octets.
The EE certificate used to sign a manifest MUST NOT be published at the authority's repository publication point. For a one-time-use key pair, the private key MUST be destroyed immediately after signing the manifest.
The EE certificate used to verify a manifest MUST have an SIA extension access description with accessMethod OID id-ad-signedobject referencing the manifest's publication URL. The EE certificate MUST describe its INRs using the 'inherit' attribute rather than explicit resource sets.
The fileHashAlg OID MUST conform to the RPKI Algorithms and Key Size Profile (RFC 6485). This OID identifies the hash algorithm used for all FileAndHash entries in the manifest.
The mandatory content-type attribute in the CMS SignedData wrapper MUST have its attrValues set to the same OID as eContentType, i.e., id-ct-rpkiManifest (1.2.840.113549.1.9.16.1.26).
The nextUpdate field MUST contain a time later than thisUpdate. If the authority alters any published objects at the publication point, it MUST issue a new manifest before the nextUpdate time.
The version field of the rpkiManifest MUST be 0. Relying parties MUST reject manifests with any other version value.
Upon creation of a CA's publication point, the CA MUST create and publish both a manifest and a CRL. A manifest will always contain at least one entry: the CRL issued by the CA upon repository creation.
A CA MAY use a 'one-time-use' EE certificate (new key pair per manifest) or a 'sequential-use' EE certificate (same key signs a sequence of manifests). For sequential-use, the same file name must be used across manifest versions to keep the EE certificate valid for the object sequence.
A manifest is a CMS SignedData object (per RFC 6488) whose eContentType is id-ct-rpkiManifest (OID 1.2.840.113549.1.9.16.1.26). It enumerates all currently valid signed objects at a CA's repository publication point, providing each object's filename and a hash of its contents.
This document registers 'Manifest' with OID 1.2.840.113549.1.9.16.1.26 in the 'RPKI Signed Object' registry created by RFC 6488.
This document registers the three-letter filename extension 'mft' for the RPKI Manifest object type in the 'RPKI Repository Name Schemes' registry created by RFC 6481.
A stale manifest (current time after nextUpdate) may indicate suppression of a newer manifest. Signed objects covered by a stale manifest SHOULD be treated as suspect because a newer CRL or revocation may have been withheld. RPs SHOULD warn about stale manifests and apply local policy on whether to use the objects.
Hash mismatches between a manifest entry and the retrieved file likely indicate a superseded object whose newer version is unavailable, possibly due to an attack. For CRLs, an RP SHOULD endeavor to use the most recently issued valid CRL even if its hash does not match the manifest entry.
Manifests enable detection of deleted or stale-substituted signed objects, but cannot repair such attacks. The manifest's signing structure and nextUpdate field allow detection of manifest tampering within the manifest update schedule; however, fine-grained replay attacks within a single update interval are not necessarily detectable.
When no valid manifest is present, there is no protection against deletion or replay of signed objects. The primary risk is that a superseded CRL causes an RP to accept a revoked certificate. RPs SHOULD warn of missing manifests and MAY fall back to a locally cached previous manifest.
Manifest validation (Section 4.4) requires an RP to: (1) verify the eContentType is id-ct-rpkiManifest, (2) confirm version is 0, and (3) confirm thisUpdate precedes nextUpdate. An invalid manifest MUST be discarded and treated as absent. Valid manifests are then subject to further RP state tests in Section 6.1.
The Manifest eContent is ASN.1 DER-encoded as a SEQUENCE containing: version (INTEGER DEFAULT 0), manifestNumber (INTEGER 0..MAX), thisUpdate (GeneralizedTime), nextUpdate (GeneralizedTime), fileHashAlg (OBJECT IDENTIFIER), and fileList (SEQUENCE OF FileAndHash). FileAndHash pairs a file name (IA5String) with a hash (BIT STRING).