The RPKI Architecture: Resource Certificates and Trust Anchors

The RPKI Architecture: Resource Certificates and Trust Anchors

The Resource Public Key Infrastructure (RPKI), standardized in RFC 6480, is a specialized Public Key Infrastructure designed to cryptographically bind Internet number resources (IPv4 blocks, IPv6 blocks, and Autonomous System Numbers) to public-key certificates held by the organizations to which those resources were formally allocated.

The RPKI Trust Model: Hierarchical Certification from RIRs

Unlike the commercial Web PKI (where hundreds of commercial Certificate Authorities can issue TLS certificates for any domain on Earth), RPKI strictly follows the hierarchical allocation chain of the Internet:

                       +-----------------------+
                       |         IANA          |
                       +-----------+-----------+
                                   |
         +------------+------------+------------+------------+
         |            |            |            |            |
         v            v            v            v            v
     AFRINIC TA   APNIC TA     ARIN TA      LACNIC TA   RIPE NCC TA
         |            |            |            |            |
         +------------+------------+------------+------------+
                                   |
                                   v
                       +-----------------------+
                       |  LIR / ISP Sub-CA     |
                       |  (e.g., Enterprise)   |
                       +-----------+-----------+
                                   |
                       +-----------+-----------+
                       |                       |
                       v                       v
               +---------------+       +---------------+
               |   ROA (AS100, |       |   Manifest    |
               |  198.51.100/24|       |  (.mft file)  |
               +---------------+       +---------------+

The tree begins at IANA and cascades down through the five Regional Internet Registries (RIRs) to Local Internet Registries (ISPs, telcos, cloud providers) and enterprise end-users. A certificate in RPKI cannot authorize resources that were not explicitly delegated down the parent chain.

Trust Anchors and Root Certificates at Each RIR

Every relying party (validator) bootstraps its validation process using Trust Anchor Locators (TALs) (RFC 8630). A TAL is a small text file containing: - The URI of the RIR’s root certificate (hosted over HTTPS or rsync). - The subject public key identifier (SPKI) and public key of the RIR’s self-signed Trust Anchor root certificate.

There are five primary Trust Anchors corresponding to the five RIRs: 1. arin.tal 2. ripe.tal 3. apnic.tal 4. lacnic.tal 5. afrinic.tal

A validator reads these TALs on startup, downloads the root certificates from the specified publication points, verifies their cryptographic fingerprints, and constructs the root of the validation tree.

Resource Certificates: Structure, Extensions and Resource Holders

RPKI certificates are standard X.509 v3 public key certificates with a critical addition: the IP Address and AS Number Extensions (RFC 3779).

In standard TLS certificates, the certificate subject is a Common Name or Domain (e.g., CN=example.com). In an RPKI certificate: - The Subject field contains a non-identifying pseudonym. - The RFC 3779 extensions explicitly list the exact IP address ranges and Autonomous System Numbers the certificate holder is authorized to manage:

X509v3 extensions:
  IP Address Delegation:
    IPv4: 198.51.100.0/24
    IPv6: 2001:db8:abcd::/48
  Autonomous System Numbers:
    AS65001

A parent CA can only issue a child certificate for a subset of the resources listed in the parent’s own certificate. If a rogue administrator at an ISP attempts to issue a certificate for someone else’s /16 block, chain validation fails immediately because the parent certificate does not contain those resources.

CA Certificates and Chain Validation

RPKI distinguishes between two certificate types: - CA Certificates (Certificate Authority): Used to sign child certificates, Certificate Revocation Lists (CRLs), and signed object lists. - End-Entity (EE) Certificates: Ephemeral, single-use certificates created solely to sign a specific payload object—such as a Route Origin Authorization (ROA) or an ASPA object. Once the object is signed, the private key is discarded.

During chain validation, a relying party walks down the cryptographic path from the RIR Trust Anchor to the EE certificate, verifying: 1. That all signatures across the path are mathematically valid (RSA or ECDSA). 2. That each certificate is within its valid start and expiration dates (notBefore / notAfter). 3. That the resources in the child certificate are strictly a sub-allocation of the parent’s RFC 3779 extensions. 4. That no certificate in the chain has been revoked on an active CRL.

Manifests and Signed Object Lists: What They Protect

Every RPKI repository publication point publishes a Manifest (RFC 6486). A manifest is a signed CMS object (.mft) that lists the filenames and SHA-256 cryptographic hashes of every valid object currently published in that repository directory.

Manifests protect relying parties against replay and deletion attacks: - If an adversary compromises a local repository mirror and deletes a valid ROA, the validator checks the manifest, detects that a listed file is missing, and raises an alarm. - If an attacker attempts to inject a revoked, stale ROA from six months ago, the manifest’s hash check fails, preventing the stale authorization from entering the router’s decision engine.