RPKI (Resource Public Key Infrastructure) is the cryptographic backbone of modern internet routing security. Defined across the RFC 6480 series starting in 2012, RPKI lets the legitimate holders of IP address blocks and AS numbers cryptographically authorize who can announce those resources in BGP. It is the technology that makes "is this network operator allowed to announce this prefix?" a question with a verifiable answer.
Unlike its sibling BGPsec (which adds path-level cryptographic verification and is barely deployed), RPKI is widely adopted. Major Tier-1 networks deploy ROA (Route Origin Authorization) validation. Cloudflare, Google, Amazon, and others routinely reject BGP announcements that fail RPKI validation. The percentage of valid IP space covered by ROAs has climbed steadily and now exceeds 50% globally for IPv4, higher for IPv6.
Migrating RPKI to post-quantum cryptography is therefore a much more consequential operational task than migrating BGPsec. It has to be done carefully, with global coordination across all five Regional Internet Registries (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC), and across thousands of relying parties (RPs) that consume RPKI data. This blog post walks through the architecture, the PQC challenges, and the migration roadmap.
RPKI In Three Paragraphs
RPKI is an X.509-based PKI specifically designed for internet number resources. The trust anchors are the five RIRs, each of which operates a Certificate Authority that issues certificates to its members. Each member can in turn issue certificates to its sub-allocations or customers. The result is a hierarchical PKI rooted in five RIR trust anchors.
The most important objects in RPKI are ROAs (Route Origin Authorizations). A ROA is a signed object that says "AS 12345 is authorized to originate prefix 192.0.2.0/24 with maximum length 24". When a BGP router (or, more commonly, a piece of software in front of the router called a Relying Party validator) receives a BGP announcement, it can check whether the announcement matches a published ROA. If yes, the route is "RPKI valid". If a contradicting ROA exists, the route is "RPKI invalid" and should be rejected.
The cryptographic primitives are signatures (currently RSA-2048 and increasingly ECDSA-P256) and hash functions (SHA-256). All ROAs and all certificates carry signatures. All published RPKI objects are pulled by RP software via rsync or RRDP (RFC 8182), validated, and consumed by routers via the RTR protocol (RFC 8210).
Why RPKI Is Easier Than BGPsec For PQC
RPKI's signatures live in static, signed objects (certificates, ROAs, manifests, CRLs) that are published and pulled. They do not flow through BGP UPDATE messages. The size constraints are filesystem-level (RRDP repositories can be hundreds of megabytes; an extra few KB per ROA does not break anything) rather than protocol-level (where BGPsec is squeezed against UDP and TCP message limits).
This means PQC migration for RPKI is fundamentally tractable. The signatures will get bigger, the published repositories will get bigger, but the operational model still works.
What Migrates: Three Object Types
Three object types need PQC algorithm support:
1. RPKI Resource Certificates. These are X.509 certificates that bind a public key to a set of internet number resources (IP prefixes and ASNs). The certificate's signature comes from the parent CA's private key. Today: RSA-2048 or ECDSA-P256. Future: ML-DSA-65 or similar.
2. ROAs (Route Origin Authorizations). Signed objects defined in RFC 6482 (and 6482bis updates) that bind a prefix to an authorized origin AS. The signature uses the resource certificate's private key. Same algorithm question.
3. Manifest objects (RFC 6486). Signed lists of all the objects in a publication point. Again, same signature.
There are also CRLs (Certificate Revocation Lists), Ghostbusters records (operational contact info), and now ASPA (Autonomous System Provider Authorization, specified in the IETF draft-ietf-sidrops-aspa-profile) objects. All use the same signature pattern.
PQC Algorithm Choice For RPKI
The natural candidate for RPKI PQC is ML-DSA, since RPKI is general-purpose certificate infrastructure and ML-DSA is the NIST-standardized general-purpose PQC signature. The IETF SIDROPS working group is exploring draft-ietf-sidrops-rpki-pq-algorithm and related drafts.
ML-DSA-65 looks like the realistic choice. ML-DSA-65 has 1,952-byte public keys and 3,309-byte signatures. For RPKI:
- A typical resource certificate today is around 1.5 KB. With ML-DSA-65 it grows to roughly 6-8 KB.
- A typical ROA is around 1 KB. With ML-DSA-65 it grows to roughly 5 KB.
- A manifest is small but signs many objects; same signature size growth.
Globally, RPKI has roughly 600,000 valid ROAs. Multiply by 4-5x size growth and the global RPKI repository would expand from its current ~5 GB to roughly 25 GB. Manageable but not trivial.
Hash Algorithm Migration
RPKI today uses SHA-256 for hashes (in CRL distribution points, manifest hashes, etc.). SHA-256 is not significantly weakened by quantum computers: Grover's algorithm halves the effective security to 128 bits, which is still considered safe.
So RPKI does not need to migrate hash algorithms for PQC reasons. Some hardening might still happen as a defense-in-depth measure (moving to SHA-512 or SHA-3), but it is not required.
Migration Strategy: Add, Don't Replace
The historical pattern in PKI migration is "add new algorithm, run both in parallel, eventually deprecate old". The same pattern applies to RPKI.
Phase 1: Algorithm registration. IETF registers new OIDs for ML-DSA-65 in X.509 certificate signature algorithms. IANA updates the relevant registries. RPs (relying party software) update to recognize ML-DSA-65 OIDs.
Phase 2: CA capability. RIRs and other CAs add ML-DSA-65 signing capability to their CA software. They do not yet issue ML-DSA-65 certificates by default.
Phase 3: Dual-issue. Resource holders can request both ECDSA-P256 and ML-DSA-65 certificates for the same resources. The CA issues both. RPs verify whichever they prefer.
Phase 4: Default ML-DSA-65 for new certificates. As RP coverage grows, default new certificate issuance to ML-DSA-65.
Phase 5: Deprecate ECDSA. Set a deprecation date. Stop issuing ECDSA. Eventually stop accepting it.
This is a multi-year process. The five RIRs each move on their own timelines, coordinated through groups like the NRO (Number Resource Organization) and through IETF SIDROPS.
Hash-Based Alternatives For The Trust Anchor
For the five RIR trust anchors specifically, there is interest in stateful hash-based signatures (LMS or HSS, RFC 8554). The reasoning:
- Trust anchor keys are signed in formal ceremonies, infrequently, in carefully audited environments.
- The state-management problem of LMS is more manageable when signing happens in scheduled ceremonies rather than continuously.
- Hash-based signatures are based on the most conservative cryptographic assumption (one-way hash functions), which is reassuring for a trust anchor that needs to last decades.
A possible future RPKI PQC topology has trust anchors signed with LMS (very long-term stability) and downstream CAs signed with ML-DSA-65 (operational efficiency).
Relying Party Software Burden
The bulk of operational concern is on the relying parties. RPKI RP software (Routinator, OctoRPKI, Validator3, FORT, RPKI Prover, rpki-client) has to:
- Implement ML-DSA-65 signature verification
- Handle larger objects in repository pull/parse paths
- Update their dependency on cryptographic libraries (which means waiting for OpenSSL 3.5+, BoringSSL, etc.)
- Test interoperability across all the RIR trust anchors
The good news is that RP software is actively maintained by small teams of dedicated developers (NLnet Labs for Routinator, Cloudflare for OctoRPKI, the rpki-client team, etc.). They are tracking the IETF work and will ship support when the standards are finalized.
Repository Bandwidth And Storage
A 5x growth in RPKI object sizes means a 5x growth in:
- RRDP repository size (the XML-based pull mechanism)
- rsync repository size (legacy pull mechanism)
- Bandwidth used by RPs to fetch updates
- Local storage on RPs to cache objects
- Memory used during validation
This is not a showstopper but it is real. RPs that today consume 5 GB of repository data per pull cycle will consume 25 GB. Network operators with bandwidth-sensitive RP deployments need to plan accordingly.
Hybrid Signatures In RPKI?
The hybrid approach (combining classical and PQC signatures) is being discussed in the IETF, but for RPKI specifically the size penalty of dual signatures is harder to swallow. Two signatures (ECDSA-P256 plus ML-DSA-65) would add 3,373 bytes per signature instead of just 3,309. Marginal cost is small but the absolute size is unavoidable.
For most RPKI use cases, single PQC signatures are likely the migration path, with the assumption that ML-DSA-65 alone is sufficient. The trust anchors might use multiple algorithms for defense in depth, but downstream certificates and ROAs probably will not.
Cross-RIR Coordination
RPKI is operated by five independent RIRs. Each has its own software, its own ceremony procedures, its own publication infrastructure. PQC migration requires all five to move in coordination: if one RIR issues only ML-DSA-65 certificates while another issues only ECDSA, RPs need to handle both. This is fine technically (PKI is built for algorithm agility) but requires operational alignment.
The NRO and the SIDROPS WG are the forums where this coordination happens. ICANN sometimes plays a coordinating role for the broader internet number ecosystem.
ASPA: A Newer Object Type With Similar PQC Story
ASPA (Autonomous System Provider Authorization) is a newer RPKI object type, defined in the IETF SIDROPS working group's ASPA profile drafts. It augments RPKI with information about which ASes act as upstream providers for which others, enabling more sophisticated path validation.
ASPA's PQC migration story is identical to ROAs': they are signed objects that will need new signature algorithms. Since ASPA is still in early deployment, the PQC migration could happen concurrently with ASPA's broader rollout.
What QNSQY Recommends
For network operators consuming RPKI today:
- Validate ROAs. This is foundational hygiene independent of PQC.
- Use modern RP software. Routinator, rpki-client, or OctoRPKI are all good. Stay current.
- Plan for storage and bandwidth growth when PQC arrives. Probably 2-3 years out for initial deployment.
- Monitor the SIDROPS WG for algorithm and protocol updates.
For resource holders publishing ROAs:
- Keep your CA software current. Whether you self-host or use your RIR's hosted CA service.
- Plan key rotation. When PQC algorithms are available, the natural migration is during a planned key rollover.
- Watch your RIR's announcements. Each RIR will roll out PQC support on its own timeline.
For QNSQY itself, we publish ROAs for our infrastructure prefixes through our hosting providers' RPKI services. PQC migration of those ROAs will happen when our providers and our RIR support it, with no action on our part beyond rotating the certificates.
Frequently Asked Questions
Q: When will RPKI actually use PQC signatures? Probably 2027-2029 for early adopters, 2030+ for full ecosystem. The pace depends on IETF standardization and RIR readiness.
Q: Will RPKI break during the migration? The migration is designed to be backward-compatible. Old RPs continue to validate ECDSA objects. New RPs validate both ECDSA and ML-DSA. Failures should be limited to misconfiguration cases.
Q: Should I switch to ECDSA from RSA in my RPKI now? Yes, if you can. ECDSA is more space-efficient and is the modern default in RPKI. It will be the easier migration source when PQC arrives.
Q: Does PQC RPKI affect home users or end customers? No. RPKI is internet infrastructure that operators care about. End users see no change.
Q: What about the Ghostbusters records and Trust Anchor Locators (TALs)? TALs are the bootstrap mechanism for RPs to find the trust anchors. They contain the trust anchor public keys directly. PQC TALs will carry ML-DSA-65 public keys (or LMS public keys for hash-based trust anchors). RPs will need to handle both types during migration.
Sources
- RFC 6480, An Infrastructure to Support Secure Internet Routing. https://datatracker.ietf.org/doc/html/rfc6480
- RFC 6482, A Profile for Route Origin Authorizations (ROAs). https://datatracker.ietf.org/doc/html/rfc6482
- RFC 6486, Manifests for the Resource Public Key Infrastructure. https://datatracker.ietf.org/doc/html/rfc6486
- RFC 8210, The Resource Public Key Infrastructure (RPKI) to Router Protocol. https://datatracker.ietf.org/doc/html/rfc8210
- RFC 8182, The RPKI Repository Delta Protocol (RRDP). https://datatracker.ietf.org/doc/html/rfc8182
- NIST FIPS 204, Module-Lattice-Based Digital Signature Standard. https://csrc.nist.gov/pubs/fips/204/final
- IETF SIDROPS Working Group. https://datatracker.ietf.org/wg/sidrops/
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.