A Profile for Resource Certificate Repository Structure
Extracted elements (29)
Because a repository may be in a partially updated state and cannot guarantee internal consistency at all times, RPs should use retrieval algorithms (e.g., double synchronization or manifest comparison) to mitigate transient inconsistency rather than assuming atomic updates.
File names for CRLs, manifests, and certificates are recommended (non-normative) to be derived from the CA's public key using a modified Base64 encoding of the 160-bit public key hash, making them stable across reissuance events and unique per key pair.
Online per-certificate retrieval using AIA, SIA, and CRLDP fields is explicitly NOT recommended; instead, each RP should maintain a local repository cache with a synchronized copy of all valid certificates, CRLs, and signed objects to support efficient validation.
The RPKI design requires each CA to be uniquely associated with a single key pair. During key rollover, a new subject name is required because RPKI mandates unique subject names across all certificates issued by a CA, and the new key creates a new CA instance.
A series of certificates issued to the same subject name, subject public key, and resource collection SHOULD share the same filename, so each successive certificate effectively overwrites the previous instance.
During CA key rollover, the entity SHOULD continue to use the same repository publication point for both CA instances, ensuring that AIA extension values in indirect subordinate objects remain valid across the key rollover.
Every repository publication point MUST contain a manifest (RFC 6486). The manifest lists the names of all objects and the hash value of each object's contents currently published by a CA or EE.
Published certificates MUST use a filename extension of '.cer' to denote the object as a certificate. Each '.cer' file contains exactly one certificate encoded in DER format.
Published RPKI signed objects MUST NOT use the filename extensions '.crl', '.mft', or '.cer'. Published ROAs MUST use a filename extension of '.roa'.
Reissued CA certificates SHOULD use the same repository publication point as previously issued CA certificates having the same subject and subject public key, so that certificate reissuance intentionally overwrites the previously issued certificate.
Repository operators SHOULD implement some form of directory management regime to ensure that RPs performing retrieval operations are not exposed to intermediate states during changes to the repository and the associated manifest.
Repository traversal SHOULD support a locally configured maximal chain length from the initial trust anchors to prevent SIA pointer loops or degenerate RPKI hierarchy forms from causing an RP to malfunction during synchronization.
RPs SHOULD ensure that local synchronization uses retrieved manifests (RFC 6486) to verify synchronization against a current, consistent state of each repository publication point.
The filename extension '.crl' MUST be used to denote a CRL file. Each '.crl' file contains exactly one CRL encoded in DER format.
The publication repository MUST be available using rsync (RFC 5781). Support of additional retrieval mechanisms is the choice of the repository operator, but supported mechanisms MUST be consistent with the accessMethod element values in the SIA of the associated CA or EE certificate.
The repository system is a collection of all signed objects that MUST be globally accessible to all relying parties. When certificates, CRLs, and signed objects are created, they are uploaded to a repository publication point for download by RPs.
When a CA issues a new CRL, it replaces the previous CRL in the repository publication point. CAs MUST NOT continue to publish previous CRLs; the new CRL MUST replace (overwrite) previous CRLs signed by the same CA instance.
When a new manifest is published, it MUST replace the previous manifest. CAs MUST NOT continue to publish previous CA manifests. The filename extension '.mft' MUST be used to denote the object as a manifest.
A CA certificate's SIA field contains two accessMethod elements: id-ad-caRepository (pointing to the repository publication point directory) and id-ad-rpkiManifest (pointing to the manifest object URI). These allow RPs to locate all issued certificates and the current manifest.
A CA's repository publication point contains: all current (non-expired, non-revoked) certificates issued by that CA; the most recent CRL issued by that CA; the current manifest; and all current signed objects verifiable by an EE certificate issued by this CA.
Signed objects (e.g., ROAs) are published in the repository publication point referenced by the SIA of the CA certificate that issued the EE certificate used to validate the object's signature; the SIA of the EE certificate references the object directly (not a directory).
The AIA extension of a certificate contains a URI that references the authoritative location for the CA certificate under which the given certificate was issued, enabling upward chain traversal in the RPKI hierarchy.
The manifest lists names and hash values of all objects in the publication point, with the single exception of the manifest itself. It is used by RPs to detect stale, missing, or substituted objects.
IANA created the 'RPKI Repository Name Scheme' registry for three-letter filename extensions for RPKI repository objects, managed by IETF Review. Initial entries: .cer (Certificate), .crl (CRL), .mft (Manifest), .roa (ROA).
IANA registered the media type 'application/rpki-manifest' with file extension '.mft' for RPKI Manifest objects as defined in RFC 6486.
IANA registered the media type 'application/rpki-roa' with file extension '.roa' for RPKI Route Origination Authorization objects as defined in RFC 6482.
Confidentiality is not provided by the repository or by signed objects published in it. Data subject to controlled access MUST NOT be included in signed objects unless a specified confidentiality mechanism is employed.
Even with manifests and CRLs, a relying party cannot detect all forms of substitution attacks based on older (but not expired) valid objects. This is a fundamental limitation of the repository model.
Repositories are not assumed to be integrity-protected databases; retrieval operations may be vulnerable to man-in-the-middle attacks. Object corruption is detectable via signature validation; object replay (substitution with older versions) is detectable via manifests; revoked certificate insertion is detected via CRL processing.