A Profile for X.509 PKIX Resource Certificates
updated by
- rfc-7318 — Policy Qualifiers in Resource Public Key Infrastructure (RPKI) Certificates
- rfc-8209 — A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests
- rfc-9829 — Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions
Extracted elements (27)
A CA instance is defined as a combination of a named entity and a specific key pair, so a CA cannot roll over its key pair in place. Instead, the entity creates a new CA instance with a new key pair and migrates all subordinate products. This bounds CRL scope to certificates issued under a single key.
Subject names are required to be unique per issuer but not globally unique, because the RPKI is a distributed PKI where no ready mechanism exists for CAs to coordinate a globally unique name space without introducing critical external dependencies.
The profile prohibits all extensions not explicitly listed, including non-critical ones, because this is a specific-use certificate. Non-critical extensions an RP does not understand might, if understood, contradict or qualify the validity judgment—so the profile adopts minimalism over extensibility.
Any change to this certificate profile—extensions, permitted attributes, optional fields, or encodings—is not backward compatible; relying parties are required to reject non-conforming certificates. A formal 3-phase transition procedure (capability, coexistence, cutover) must be followed for all profile updates, coordinated across all CAs and RPs.
An EE certificate's private key is used to sign a single RPKI signed object (one-time-use), and the EE certificate is embedded in the CMS signed-data structure. 'Sequential use' EE certificates MAY sign a sequence of manifests where each overwrites the previous.
Each CA MUST issue a version 2 CRL consistent with RFC 5280. CRLs MUST NOT include Indirect or Delta CRLs. Only the Authority Key Identifier and CRL Number extensions are allowed; no CRL entry extensions are permitted, and only Serial Number and Revocation Date fields may appear per revoked certificate.
Each distinct subordinate CA and EE certified by the issuer MUST be identified using a subject name that is unique per issuer, where 'distinct' is defined as an entity and a given public key. An issuer SHOULD use a different subject name if the subject's key pair has changed.
Every resource certificate MUST contain either the IP Address Delegation or the Autonomous System Identifier Delegation extension (or both), and these extensions MUST be marked as critical. The sorted canonical format with maximal spanning ranges MUST be used for the resource extension field.
For resource extension validation, for every adjacent pair of certificates in the certification path, the number resources in certificate x must 'encompass' the resources in certificate x+1. 'Encompass' means every range in the subject's set is more specific than or equal to a range in the issuer's set.
Resource certificates MUST be X.509 version 3 (field value 2). Relying Parties need not process version 1 or version 2 certificates, in contrast to RFC 5280.
Revocation check requires that the public key used to verify the signature on the CRL is the same public key used to verify the certificate itself. A relying party using separate validation paths for a certificate and its CRL risks incorrect revocation decisions.
The Certificate Policies extension MUST be present, MUST be marked critical, and MUST include exactly one policy OID as specified in the RPKI Certificate Policy (RFC 6484).
The Extended Key Usage extension MUST NOT appear in any CA certificate in the RPKI, and MUST NOT appear in EE certificates used to verify RPKI objects such as ROAs or manifests. The extension MAY appear in EE certificates issued to routers or other devices.
The Issuer name MUST contain one instance of the CommonName attribute encoded as ASN.1 PrintableString, and MAY contain one instance of the serialNumber attribute. The RPKI does not rely on issuer names being globally unique.
Basic Constraints is a critical extension that MUST be present when the subject is a CA and MUST NOT be present otherwise. The Path Length Constraint MUST NOT be present in any RPKI certificate.
For CA certificates, the Subject Information Access extension MUST be present and non-critical, and MUST include both an id-ad-caRepository entry (rsync URI to the CA's publication directory) and an id-ad-rpkiManifest entry (OID id-ad 10, rsync URI to the CA's manifest).
For EE certificates, the SIA extension MUST be present and non-critical, and MUST include an id-ad-signedObject entry (OID id-ad 11) with an rsync URI pointing to the signed object verified by this EE certificate. Other AccessMethods MUST NOT be used.
The AS Resources extension (from RFC 3779), if present, MUST be marked critical and MUST either specify a non-empty set of AS number records or use the 'inherit' element. Routing Domain Identifier (RDI) values MUST NOT be used.
The Authority Information Access extension is non-critical and MUST be present except in self-signed certificates. It MUST include an rsync URI with accessMethod id-ad-caIssuers pointing to the immediate superior certificate's publication point.
The Authority Key Identifier extension MUST appear in all resource certificates except self-signed certificates; it is non-critical. The authorityCertIssuer and authorityCertSerialNumber fields MUST NOT be present.
The CRL Distribution Points extension is non-critical and MUST be present except in self-signed certificates. It MUST contain a single DistributionPoint with a fullName URI, and an rsync URI MUST be present referencing the issuer's most recent CRL.
The IP Resources extension (from RFC 3779), if present, MUST be marked critical and MUST either specify a non-empty set of IP address records or use the 'inherit' element. The SAFI value MUST NOT be used for public Internet certificates.
The Key Usage extension is critical and MUST be present. CA certificates MUST set only keyCertSign and CRLSign; EE certificates MUST set only digitalSignature.
The Subject Key Identifier extension MUST appear in all resource certificates and is non-critical. The Key Identifier is the 160-bit SHA-1 hash of the DER-encoded ASN.1 bit string of the Subject Public Key.
Subject name collisions arising from CAs not following entropy guidelines for name generation, combined with an RP using a non-conformant path construction implementation, may cause an RP to conclude that a valid certificate has been revoked. A resource certificate PKI cannot resolve ambiguity when two or more valid certificates encompass the same resource.
The same key that signs issued certificates must also sign the CRL that can revoke those certificates. Using a validation implementation capable of using separate paths for a certificate and its CRL may cause an RP to incorrectly conclude a valid certificate has been revoked.
Resource certification path validation requires: (1) subject of cert x is issuer of cert x+1; (2) cert 1 is issued by a trust anchor; (3) each cert is valid per RFC 5280 plus RPKI constraints; (4) each cert's resources are encompassed by the issuer's resources; (5) certificate is not revoked per issuer's current CRL verified with the same public key.