| Internet-Draft | pqRPKI | July 2026 |
| Li & Chung | Expires 21 January 2027 | [Page] |
The Resource Public Key Infrastructure (RPKI) authenticates Internet number resource holdings and routing authorizations with classical (RSA) signatures. Because every relying party repeatedly fetches and validates the complete global repository, replacing each per-object signature with a larger post-quantum signature would multiply repository size and validation cost.¶
This document specifies pqRPKI, an additive post-quantum authentication layer for the RPKI. Instead of re-signing every object, each Certification Authority (CA) authenticates its complete published state with a single post-quantum signature over a Merkle Tree Ladder whose leaf order and leaf commitments are taken directly from the CA's existing Manifest. A new signed object, the pqRPKI Ladder Object (PQLO), carries the ladder root, the Manifest binding, an optional aggregate binding the CA's children, and -- for a Trust Anchor or a CA holding its own post-quantum key -- the post-quantum signature; a CA operated by its parent is authenticated through the parent's aggregate instead. Existing RPKI objects are unchanged and legacy relying parties are unaffected by the PQLO, which no Manifest lists, while upgraded relying parties validate the same repository contents with post-quantum authentication. This document updates RFC 9286 to permit index-preserving placeholder Manifest entries and the pqRPKI file-name extension.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 21 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The RPKI [RFC6480] secures Internet routing by binding Internet number resources (IP address prefixes and Autonomous System numbers) to the entities authorized to use them, and by letting those entities publish signed objects such as Route Origin Authorizations (ROAs) [RFC9582]. A Relying Party (RP) fetches the contents of publication points, validates certificate and signed-object chains up to one or more preconfigured Trust Anchors (TAs), and emits validated payloads (for example, Validated ROA Payloads) that routers consume.¶
Unlike handshake-driven public-key infrastructures, RPKI validation is inherently bulk: an RP periodically retrieves and validates essentially the complete global corpus across all trust anchors and delegated publication points, on an operational cadence (commonly 20 to 60 minutes, and at least every 24 hours). Each publication point is anchored by two mandatory, frequently reissued artifacts: the Manifest [RFC9286], which enumerates every current file and its SHA-256 hash, and the Certificate Revocation List (CRL); RPKI validation rejects any file that is not listed on the current Manifest with a matching hash.¶
This bulk model makes the post-quantum transition both urgent and difficult. Post-quantum signature algorithms have substantially larger public keys and signatures than RSA-2048; even the most compact standardized option (FN-DSA / Falcon) has signatures and public keys roughly three times the size of RSA-2048. A per-object substitution multiplies that penalty across hundreds of thousands of objects that every RP downloads and validates every cycle, and inflates the frequent reissuance of Manifests, CRLs, and their one-time-use end-entity (EE) certificates. A direct substitution is poorly matched to RPKI for four reasons:¶
pqRPKI exploits RPKI's repository structure instead of fighting it. It applies an RPKI-specific Merkle Tree Ladder (MTL) [I-D.harvey-cfrg-mtl-mode] per CA: many objects are hashed into a ladder of bounded-depth Merkle trees ("rungs"), and a single post-quantum signature protects the compact ladder root. The ladder reuses two things the Manifest already provides: the file-list order (which induces each leaf's index) and each file's existing SHA-256 hash (which serves as that leaf's commitment). No per-object Merkle authentication paths are attached to objects; an upgraded RP reconstructs the shared internal nodes once per cycle and reuses them across all objects of a CA.¶
This document specifies the cryptographic construction to the byte level (Section 4), the pqRPKI Ladder Object (Section 5), and parent aggregation and delegation (Section 6). It further specifies the updates to RFC 9286 that make the Manifest-derived leaf semantics and placeholder entries interoperable (Section 7), post-quantum trust-anchor distribution (Section 8), and the algorithm profile (Section 9). Issuer and RP behavior are specified in Section 10 and Section 11.¶
This document updates [RFC9286] in three ways. It extends the Manifest file-name grammar to admit the pqRPKI file-name extension (Section 7.3). It admits one deliberate exception to the rule that every published signed object is listed on a Manifest (Section 7.4). Finally, it defines index-preserving placeholder Manifest entries and their processing (Section 7.5). It does not change the Manifest ASN.1 syntax, and it does not define or require any X.509 certificate extension.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses the RPKI terminology of [RFC6480], [RFC6487], [RFC6488], and [RFC9286]. It additionally defines:¶
manifestHash, this position is itself authenticated; no separate index field is carried.¶
pqRPKI adds authentication; it removes nothing. During migration a CA continues to publish ordinary RPKI certificates, CRLs, Manifests, and signed objects exactly as today, and additionally publishes exactly one PQLO at its own publication point, beside its Manifest. The PQLO is produced together with each Manifest, but -- like the Manifest itself, which no fileList names -- it is never listed on any Manifest (Section 5.2). Keeping the PQLO off the fileList is what lets it commit to the Manifest without a circular dependency, and keeps its reissuance from rippling into any other object. Legacy RPs disregard it entirely (Section 12); upgraded RPs validate the ordinary object set and, in addition, the pqRPKI authentication state. A Trust Anchor's PQLO is additionally referenced from the pqTAL (Section 8).¶
The Manifest is pqRPKI's shared verification channel. It already lists every file an RP must consider for a CA and already carries a SHA-256 hash for each listed file. pqRPKI therefore derives the CA Ladder's object-leaf order from the Manifest FileAndHash sequence and uses each Manifest hash directly as the corresponding leaf commitment. No new per-object data structure is introduced, and ordinary objects (ROAs, ASPAs, certificates, CRLs) are unchanged on the wire.¶
A single fixed-depth Merkle tree supports only a fixed number of leaves and must be rebuilt once exhausted. A ladder instead links a sequence of bounded-depth trees (rungs): as leaves accumulate, smaller rungs merge into larger ones (for example, 14 object leaves occupy rungs of sizes 8, 4, and 2, which merge into a single rung of size 16 when the 16th object leaf appears). Appending or changing a small number of leaves touches only a short suffix of the ladder and its upward hash path.¶
The Manifest and CRL are reissued far more often than routing objects. Placing them inside object rungs would make every routine refresh propagate through Merkle roots and force widespread recomputation and re-authentication even when no routing object changed. pqRPKI therefore models the Manifest and CRL as single-leaf, depth-0 metadata rungs appended after all object rungs (Section 4.5). This isolates metadata churn to a short ladder suffix, keeping every object leaf, index, and cached subtree stable across metadata refreshes.¶
Each pqRPKI-aware CA has its own CA Ladder whose root authenticates that CA's published state. A parent CA authenticates its children by carrying an aggregate ladder in its own PQLO (Section 6). For a hosted child -- a CA operated by the parent, with no post-quantum key of its own -- the aggregate binds a hash of the child's entire PQLO TBS. For a delegated child -- a CA holding its own post-quantum key -- the aggregate binds only that public key, so the child refreshes its Manifest and PQLO on its own cadence without any parent involvement, and the parent's aggregate changes only when the child's key rolls.¶
The two binding modes give pqRPKI its operational shape. A registry operating a large hosted population updates its members' ladders and aggregates bottom-up and re-signs once, at the nearest CA holding a post-quantum key, per coalesced batch of changes -- one post-quantum signature amortized over the whole batch. Delegated subtrees are fully decoupled from their parents. At the top, the Trust Anchor's post-quantum public key is preconfigured at RPs through the pqTAL (Section 8) and transitively authenticates every PQLO beneath it.¶
Trust Anchor post-quantum public key (preconfigured via pqTAL)
| verifies
v
TA PQLO: pqSignature over TBS
TBS = ladderRoot + Manifest binding + aggregate
|
| aggregate leaves bind children:
| hosted: SHA-256 of child PQLO TBS
| delegated: child post-quantum public key
v
Child CA PQLO: TBS (hosted: bound by parent aggregate;
| delegated: signed with child's own PQ key)
v
ladderRoot ---> Manifest FileAndHash order and hashes
| induce indices i and commitments H0[i]
v
Object leaves (ROAs, ASPAs, certs, placeholders)
+ CRL and Manifest metadata rungs
This section defines the CA Ladder and its root exactly, so that independent implementations produce byte-identical results.
All values in this section are octet strings; all hashing is SHA-256 ([RFC6234]) producing 32-octet outputs; and every multi-octet integer is encoded big-endian.
The hash algorithm is carried explicitly in the PQLO (field hashAlgorithm, Section 5.3) so a future profile may substitute a stronger hash; SHA-256 is the only value defined by this document because it is already the Manifest hash algorithm.¶
Four fixed 16-octet domain-separation tags distinguish the hash inputs of different construction steps so that a hash computed for one purpose can never be reinterpreted as another. They are protocol constants; implementations MUST use exactly these octets and MUST NOT derive them at runtime.¶
| Name | ASCII (NUL-padded to 16) | Hex |
|---|---|---|
| DSEP_LEAF | "pqRPKI/leaf/v0\0\0" | 70 71 52 50 4b 49 2f 6c 65 61 66 2f 76 30 00 00 |
| DSEP_NODE | "pqRPKI/node/v0\0\0" | 70 71 52 50 4b 49 2f 6e 6f 64 65 2f 76 30 00 00 |
| DSEP_LROOT | "pqRPKI/lroot/v0\0" | 70 71 52 50 4b 49 2f 6c 72 6f 6f 74 2f 76 30 00 |
| DSEP_LADDER | "pqRPKI/ladder/v0" | 70 71 52 50 4b 49 2f 6c 61 64 64 65 72 2f 76 30 |
DSEP_NODE tags internal Merkle nodes (Section 4.4). DSEP_LROOT tags the ladder-root reduction (Section 4.6). DSEP_LADDER tags the TBS byte string that is signed or, for a hosted CA, hashed into the parent's binding (Section 5.4). DSEP_LEAF tags aggregate leaves that commit to a child's TBS hash or public key (Section 6). Object-ladder leaves derived from the Manifest are NOT re-hashed and carry no tag (Section 4.2).¶
For an object leaf derived from a Manifest FileAndHash entry, the leaf commitment is the entry's hash value used verbatim:¶
H0[i] = FileAndHash[i].hash ; 32 octets, from the Manifest¶
The file name is NOT included in the commitment (it governs ordering only, Section 4.3); the index i is NOT included (it is implicit in position); and no domain-separation tag is applied at the object-leaf level. Reusing the Manifest hash as the commitment is what makes pqRPKI additive: for every ordinary object, the value an RP needs is already present in the Manifest and is verified against the object bytes by ordinary RPKI validation. Consequently, an RP MUST have verified, as part of ordinary RPKI validation, that a fetched object's SHA-256 hash equals its Manifest hash before using that hash as a leaf commitment; a mismatch is a Manifest validation failure for both ordinary and pqRPKI validation. This applies to every object leaf other than a placeholder entry (Section 7.2), which corresponds to no fetchable file and whose commitment is therefore not checked against any object.¶
The 32 octets committed by a metadata leaf and by an aggregate leaf are defined in Section 4.5 and Section 6 respectively.¶
Let the validated Manifest fileList be the DER wire-order sequence of FileAndHash entries. The fileList of a pqRPKI-aware CA MUST contain exactly one entry whose file name carries the ".crl" extension ([RFC6481]); if it contains none or several, pqRPKI validation of that CA fails. The CA Ladder's object leaves are obtained by processing the sequence in order and separating the two metadata entries:¶
A CA's own PQLO is published at this same publication point but is never listed on any Manifest (Section 5.2), so it never appears in the fileList and is not an object leaf.
This is deliberate: the PQLO commits to the Manifest (through manifestHash and the Manifest metadata rung), so listing it on that Manifest would make the Manifest bytes depend on the PQLO's hash and the PQLO's content depend on the Manifest bytes -- an unresolvable cycle.
Keeping the PQLO outside the fileList breaks the cycle and keeps routine PQLO reissuance from perturbing any leaf.¶
Leaf order is the Manifest wire order, taken verbatim.
Because the exact DER byte sequence of the Manifest eContent is hashed into manifestHash, which is post-quantum authenticated (Section 5.4), the order -- and hence every leaf index -- is authenticated directly; no lexicographic ordering is required and no per-leaf index field is carried.
An RP MUST use the wire order it validated and MUST NOT re-sort.
To keep leaf indices stable across reissues within a signing epoch, an issuer SHOULD hold fileList slots stable: new leaves are appended, and a removed or hidden leaf is replaced in its existing slot by a placeholder (Section 7.2) rather than dropped, subject to the legacy-compatibility constraint of Section 7.5.
An issuer that does not do so MUST rebuild the affected object rungs; index shifts are not visible to an RP, because Section 11 rederives every leaf index from the current Manifest on each cycle.
Holding slots stable is therefore an issuer-side optimization that bounds rebuild cost, not an interoperability requirement.
Reassigning indices (compaction) then happens only at an epoch boundary (Section 10).¶
Let K be the number of object leaves. The object leaves are partitioned into consecutive rungs whose sizes are the binary decomposition of K, largest first: writing K in binary, each set bit contributes one rung of that power-of-two size, from the most-significant set bit down to the least-significant. For example, K = 14 = 8 + 4 + 2 yields rung sizes [8, 4, 2]; K = 1 yields [1]; K = 3 yields [2, 1]; K = 0 yields no object rungs at all (the ladder then consists of the two metadata rungs alone). The rung sizes are strictly decreasing powers of two, and the first rung consumes object leaves [0, s0), the next [s0, s0+s1), and so on.¶
Each rung is a perfect binary Merkle tree over its consecutive leaves. An internal node combining a left child L and a right child R (each 32 octets) is:¶
node(L, R) = SHA-256( DSEP_NODE || L || R ) ; 80-octet input¶
The rung root is computed bottom-up: pair consecutive nodes (leaf 0 with leaf 1, leaf 2 with leaf 3, ...) using node() to form the next level, and repeat until one node remains.
Because every rung size is a power of two, each level always has an even node count and halves cleanly; there is never a lone node to promote or duplicate.
A rung of size 1 has a rung root equal to its single leaf, with no hashing applied.
No index, depth, or level counter is mixed into node(); separation across rungs and ladders is provided by the ladder-root and signing steps below.¶
After the object rungs, a CA Ladder appends exactly two single-leaf, depth-0 metadata rungs, in this order:¶
manifestHash field (Section 5.3).
Hashing the eContent rather than the complete file keeps the post-quantum layer independent of the CMS envelope, which a future post-quantum-only profile may change.¶
Modeling the Manifest and CRL as trailing depth-0 rungs means a routine Manifest or CRL refresh changes only these two rung roots and the ladder-root reduction, while every object leaf, object index, and cached object subtree is unchanged. This yields O(1) ladder work per metadata refresh regardless of repository size.¶
Let the ordered rung roots be R[0], R[1], ..., R[k-1] for the object rungs (largest first), followed by R_crl and R_mft for the two metadata rungs. The ladder root is a single SHA-256 over the tag, the object-leaf count K as an 8-octet big-endian integer, and the concatenation of all rung roots in that order:¶
ladderRoot = SHA-256( DSEP_LROOT
|| uint64_be(K) ; 8 octets, K = leaf count
|| R[0] || ... || R[k-1] ; object rungs
|| R_crl ; CRL metadata rung
|| R_mft ) ; Manifest metadata rung
¶
The input length is 16 + 8 + 32*(k + 2) octets, where k = popcount(K).
Folding K into the reduction ensures that two ladders with coincidentally equal rung roots but different object-leaf counts cannot collide.
A CA Ladder always has the two metadata rungs, so k+2 rung roots always appear.
The parent aggregate ladder (Section 6) uses the same reduction over its child rungs but has no metadata rungs; its distinct structure and its placement in a separate signed TBS field prevent confusion between an aggregateRoot and a ladderRoot.¶
Suppose a CA's Manifest lists 14 ordinary objects (any mix of ROAs, ASPAs, and subordinate certificates), one CRL, and nothing else (the Manifest never lists itself, and the CA's PQLO is never listed). Removing the CRL entry as the CRL metadata leaf leaves K = 14 object leaves with commitments H0[0..13] taken verbatim from the Manifest. The object rung sizes are decompose(14) = [8, 4, 2]:¶
Object rung 0 (size 8): perfect tree over H0[0..7] -> R[0]
Object rung 1 (size 4): perfect tree over H0[8..11] -> R[1]
Object rung 2 (size 2): perfect tree over H0[12..13] -> R[2]
where, e.g., R[2] = node( H0[12], H0[13] )
= SHA-256( DSEP_NODE || H0[12] || H0[13] )
and R[1] = node( node(H0[8],H0[9]), node(H0[10],H0[11]) )
Metadata rungs:
R_crl = SHA-256(CRL file) (= the CRL's Manifest hash)
R_mft = SHA-256(Manifest eContent) (= manifestHash)
ladderRoot = SHA-256( DSEP_LROOT || uint64_be(14)
|| R[0] || R[1] || R[2] || R_crl || R_mft )
¶
When the 16th object appears, rungs [8,4,2] plus two new leaves reorganize into a single object rung of size 16 (decompose(16) = [16]); the metadata rungs are re-appended unchanged in structure. Reference leaf/rung/root test vectors are maintained with the reference implementations (Appendix "Implementation Status").¶
The PQLO is an RPKI signed object conforming to [RFC6488].
Per RFC 6488 Section 4, this document defines the three elements a new signed-object type must define: the eContentType OID (Section 5.3), the eContent syntax (Section 5.3), and the additional validation steps (Section 11).
As for every RPKI signed object, the PQLO is a CMS SignedData with CMSVersion 3, a single SHA-256 DigestAlgorithmIdentifier, and exactly one embedded one-time-use EE certificate whose SubjectKeyIdentifier equals the SignerInfo sid.
The crls field is omitted.
The single SignerInfo carries the content-type and message-digest signed attributes (and optionally signing-time and/or binary-signing-time, and no others), and unsignedAttrs is omitted.¶
The EE certificate is an ordinary RPKI EE certificate ([RFC6487]) issued by the CA that the PQLO authenticates -- the same CA that issues the EE certificate of its Manifest.
Its Subject Information Access id-ad-signedObject accessLocation points at the published PQLO, and its resources are set to inherit.
The CMS signature (RSA during dual-stack) provides ordinary RPKI integrity for the file; pqRPKI authentication comes from the post-quantum signature carried inside the eContent (Section 5.4) or, for a hosted CA, from the parent's aggregate binding (Section 6.1).¶
Exactly one PQLO exists per pqRPKI-aware CA.
A PQLO carries the authenticated CA's own ladder (ladderRoot, rungDescriptors); if that CA has pqRPKI-aware children it additionally carries an aggregate over them (aggregate, Section 6).¶
A CA's PQLO is published at that CA's own publication point -- the repository directory referenced by the caRepository SIA accessLocation of the CA's certificate -- beside the CA's Manifest.
It MUST be published in the same repository update as the Manifest it commits to, so that an RP never observes one without the other; a publication server reached through the publication protocol [RFC8181] can carry both in a single atomic exchange, and an RRDP delta [RFC8182] then delivers them together.¶
The PQLO's file name is the file name of the CA's Manifest with the extension replaced by the pqRPKI extension of Section 7.3 (written ".pq" in this document).
An RP already learns the Manifest's URI from the rpkiManifest SIA accessLocation of the CA certificate ([RFC6487]); it derives the PQLO's URI from that URI by substituting the extension.
No new certificate field or access method is needed.
If the Manifest file name changes, the rules of [RFC9981] apply and the PQLO file name follows the new Manifest name.¶
The PQLO MUST NOT be listed on any Manifest (Section 7.4). Listing it on the CA's own Manifest would create the circular dependency described in Section 4.3 -- the same dependency that, as [RFC9286] notes, is why a Manifest cannot list itself. Listing it on the parent's Manifest instead would couple every child Manifest refresh to a reissue of the parent's Manifest -- and, transitively, of every ancestor's Manifest and PQLO up to the Trust Anchor -- turning routine per-CA refreshes into global churn. Like the Manifest itself, which no fileList names, the PQLO exists outside Manifest-based validation. [RFC9286] Section 6 requires that files not listed on a Manifest not be used to validate certificates, ROAs, and CRLs, but provides that such files MAY be employed to validate other signed objects where the profile of the object type explicitly states that this is allowed. This document is that profile for the PQLO, and so states: a pqRPKI-aware RP MUST retrieve and validate a PQLO as specified in Section 11 even though no Manifest lists it (Section 7.4). RFC 9286 further notes that relying on unlisted files may permit substitution attacks against them; Section 14 describes how PQLO substitution and suppression are detected.¶
An RP learns that a CA is pqRPKI-aware -- and therefore that a PQLO exists to fetch -- from the ChildBinding for that CA in its parent's authenticated aggregate (Section 6) or, for a Trust Anchor, from the presence of a configured pqTAL (Section 8). For a pqRPKI-aware CA, a missing, stale, or mismatching PQLO is a pqRPKI validation failure for that CA (Section 11); because awareness is asserted post-quantum authentically above the CA, an adversary cannot downgrade a CA out of pqRPKI by withholding its PQLO (Section 14).¶
A Trust Anchor's PQLO follows the same publication and naming rule at the Trust Anchor's own publication point; in addition, the pqTAL carries its retrieval URIs explicitly (Section 8).¶
The following ASN.1 module defines the PQLO eContent, importing CONTENT-TYPE from the CMS module of [RFC6268] and the algorithm-identifier machinery and SubjectPublicKeyInfo from [RFC5912].
Object identifiers marked TBD are assigned by IANA (Section 15).
The eContent of the PQLO CMS SignedData is a PqRPKILadder value, DER-encoded.¶
PQRPKI-2026
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs9(9) smime(16) mod(0)
id-mod-pqrpki-2026(TBD) }
DEFINITIONS EXPLICIT TAGS ::=
BEGIN
IMPORTS
CONTENT-TYPE
FROM CryptographicMessageSyntax-2010 -- in [RFC6268]
{ iso(1) member-body(2) us(840) rsadsi(113549)
pkcs(1) pkcs-9(9) smime(16) modules(0)
id-mod-cms-2009(58) }
AlgorithmIdentifier{}, ALGORITHM
FROM AlgorithmInformation-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-algorithmInformation-02(58) }
SubjectPublicKeyInfo
FROM PKIX1Explicit-2009 -- RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) };
-- Algorithm sets are placeholders pending the RPKI post-quantum
-- algorithm profile (Section 9): id-sha256 for hashAlgorithm;
-- FN-DSA-512 / ML-DSA-65 identifiers for pqSignatureAlgorithm.
HashAlgorithms ALGORITHM ::= { ... }
PqSigAlgorithms ALGORITHM ::= { ... }
-- The PQLO eContentType.
id-ct-pqrpkiLadder OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) id-smime(16)
id-ct(1) TBD }
ct-pqrpkiLadder CONTENT-TYPE ::=
{ TYPE PqRPKILadder IDENTIFIED BY id-ct-pqrpkiLadder }
-- The signed-object payload (eContent).
-- pqSignature is present for a Trust Anchor and for any delegated
-- CA (a CA holding its own post-quantum key); it is absent for a
-- hosted CA, whose TBS is authenticated through the parent's
-- aggregate (Section 6).
PqRPKILadder ::= SEQUENCE {
tbs PqRPKILadderTBS,
pqSignature PqSignature OPTIONAL }
PqRPKILadderTBS ::= SEQUENCE {
version INTEGER DEFAULT 0,
caKeyIdentifier KeyIdentifier, -- SKI of CA certificate
manifestHash Digest32, -- R_mft, Section 4.5
manifestNumber INTEGER (0..MAX), -- equals the Manifest's
thisUpdate GeneralizedTime, -- equals the Manifest's
nextUpdate GeneralizedTime, -- equals the Manifest's
hashAlgorithm AlgorithmIdentifier{{HashAlgorithms}},
-- id-sha256 here
pqSignatureAlgorithm [1] AlgorithmIdentifier{{PqSigAlgorithms}}
OPTIONAL,
-- present iff pqSignature is present
ladderRoot Digest32, -- Section 4.6
rungDescriptors SEQUENCE SIZE (2..MAX) OF RungDescriptor,
-- >= 2: the two metadata rungs always appear
aggregate [0] Aggregate OPTIONAL }
RungDescriptor ::= SEQUENCE {
kind RungKind,
firstLeafIndex INTEGER (0..MAX), -- 0 for metadata rungs;
-- first child if aggregate
leafCount INTEGER (1..MAX), -- 1 for metadata rungs
depth INTEGER (0..MAX), -- log2(leafCount)
rungRoot Digest32 }
RungKind ::= ENUMERATED {
object(0), crlMetadata(1), manifestMetadata(2), aggregate(3) }
-- Carried by a parent CA that authenticates pqRPKI children
-- (Section 6). aggregateRungs descriptors use kind aggregate(3);
-- aggregateRoot reduces the child rungs only (no metadata rungs).
Aggregate ::= SEQUENCE {
aggregateVersion INTEGER DEFAULT 0,
aggregateRoot Digest32, -- Section 6, over children
aggregateRungs SEQUENCE SIZE (1..MAX) OF RungDescriptor,
children SEQUENCE SIZE (1..MAX) OF ChildBinding }
-- Exactly one of childTBSHash (hosted) and childPQPublicKey
-- (delegated) is present, matching childMode.
ChildBinding ::= SEQUENCE {
childKeyIdentifier KeyIdentifier, -- child CA cert SKI
childMode ChildMode,
childCertificateHash Digest32, -- SHA-256, child .cer
childTBSHash [0] Digest32 OPTIONAL,
-- hosted: SHA-256 of DSEP_LADDER ||
-- DER(child PqRPKILadderTBS), Section 5.4
childPQPublicKey [1] SubjectPublicKeyInfo OPTIONAL }
-- delegated: child's post-quantum key
ChildMode ::= ENUMERATED { hosted(0), delegated(1) }
PqSignature ::= BIT STRING -- PQ signature value
KeyIdentifier ::= OCTET STRING (SIZE(20)) -- RFC 6487 SHA-1 SKI
Digest32 ::= OCTET STRING (SIZE(32)) -- SHA-256 output
END
¶
Field constraints and cross-checks (all normative):¶
pqSignature is present (that is, for a Trust Anchor or a delegated CA), and identifies its algorithm (Section 9).
A delegated child's key algorithm is carried self-descriptively in the childPQPublicKey SubjectPublicKeyInfo of its ChildBinding and need not match the parent's.¶
rungRoot MUST equal the corresponding rung root, and each descriptor's depth MUST equal log2(leafCount); the sequence MUST be consistent with an object-leaf count K whose binary decomposition equals the object rung sizes.
An RP MUST verify that the sequence corresponds exactly to the rung sequence it reconstructs, including its length, and MUST reject the PQLO otherwise.
Descriptors are redundant with the Manifest-derived reconstruction and exist so an RP can cross-check and so metadata rung roots are conveyed explicitly; an RP MUST NOT rely on them in place of reconstruction.¶
childKeyIdentifier octet value and MUST NOT contain two bindings with the same childKeyIdentifier.
In each ChildBinding, childTBSHash MUST be present and childPQPublicKey absent when childMode is hosted, and the reverse when childMode is delegated; childCertificateHash is SHA-256 of the child's CA certificate as published.¶
The post-quantum signature pqSignature, when present, is computed over the domain-separated DER encoding of the TBS:¶
signingInput = DSEP_LADDER || DER( PqRPKILadderTBS ) pqSignature = PQ-Sign( signerPrivateKey, signingInput )¶
An implementation MUST compute this input, and the hosted childTBSHash, over the exact octets of the tbs field as they appear in the PQLO it fetched, and MUST independently verify that those octets are valid DER; it MUST NOT re-encode a parsed value for this purpose.
A PQLO whose eContent is not valid DER MUST be rejected.
The same rule applies to DER(childPQPublicKey) in an aggregate leaf (Section 6).¶
For a hosted CA the identical byte string is hashed instead of signed: its SHA-256 is the childTBSHash that the parent binds in its aggregate (Section 6.1).
In both cases the value authenticated is the entire TBS.¶
Authenticating the whole DER-encoded PqRPKILadderTBS means the post-quantum layer binds not only ladderRoot but also the freshness fields (manifestHash, manifestNumber, thisUpdate, nextUpdate), the algorithm identifiers, the rung structure, and any child aggregate.
This is essential in post-quantum-required mode, where the surrounding RSA CMS signature is no longer relied upon and the post-quantum layer is the sole integrity guarantee over those fields.
The 16-octet DSEP_LADDER prefix domain-separates this input from any other use of the same post-quantum key.
Where a signature algorithm accepts a separate context-string input (for example, ML-DSA), the context is empty; domain separation is provided uniformly by the DSEP_LADDER prefix so that the same signing-input rule applies to every algorithm.
Signature values may be randomized; implementations MUST NOT assume two signatures over the same input are byte-identical.¶
A parent CA authenticates its pqRPKI-aware children through an aggregate ladder carried in the parent's own PQLO.
The aggregate is a ladder (Section 4.4, Section 4.6) whose leaves are the parent's children.
Its root, aggregateRoot, is part of the parent's TBS and is therefore authenticated exactly as the rest of the parent's TBS is: by the parent's own post-quantum signature, or -- if the parent is itself hosted -- through the grandparent's aggregate.
Unlike object leaves, aggregate leaves ARE domain-separated and hashed:¶
hosted child: childLeaf = SHA-256( DSEP_LEAF
|| childTBSHash )
delegated child: childLeaf = SHA-256( DSEP_LEAF
|| DER(childPQPublicKey) )
¶
Here DER(childPQPublicKey) is the DER encoding of the SubjectPublicKeyInfo value itself (universal SEQUENCE tag), not of the context-tagged field as it appears inside ChildBinding; the computation of childTBSHash is defined in Section 5.4.¶
Aggregate leaves are ordered by increasing childKeyIdentifier octet value (lexicographic over the 20-octet SKI), the same order as the children sequence.
The leaf list is packed into rungs whose sizes are the binary decomposition of the child count Kc, and each rung root Rc[j] is computed exactly as in Section 4.4 (perfect binary trees using node()).
Unlike a CA Ladder, an aggregate has no metadata rungs; its descriptors carry kind = aggregate(3), and its root reduces only the child rungs:¶
aggregateRoot = SHA-256( DSEP_LROOT
|| uint64_be(Kc) ; Kc = number of children
|| Rc[0] || ... || Rc[kc-1] ) ; child rungs
¶
The input length is 16 + 8 + 32*kc octets, kc = popcount(Kc).
This is the CA-Ladder reduction (Section 4.6) with the two metadata rung roots absent; folding Kc keeps counts distinct, and the absence of metadata rungs plus the value's placement in the dedicated aggregate TBS field distinguish an aggregateRoot from a ladderRoot.
Each ChildBinding also carries childCertificateHash (SHA-256 of the child's CA certificate), binding the aggregate to the RPKI certificate identity that an RP independently validates.¶
A hosted binding covers the hash of the child's entire TBS rather than the child's ladder root alone. The TBS contains the ladder root, but also the child's Manifest freshness fields, its rung descriptors, and -- crucially -- the child's own aggregate if the child in turn has pqRPKI-aware children. Binding the whole TBS therefore authenticates arbitrarily deep chains of hosted CAs with no additional mechanism (registry deployments commonly interpose an operator-run intermediate CA between the Trust Anchor and member CAs), and leaves nothing in a hosted PQLO outside the post-quantum trust chain.¶
In hosted mode the parent (typically a registry) operates the child CA: it holds the child's RPKI key, issues the child's Manifest, and runs the child's publication point.
It equally produces the child's PQLO and publishes it at the child's publication point (Section 5.2).
A hosted PQLO carries no pqSignature and no pqSignatureAlgorithm: the child holds no post-quantum key.
Instead, the parent's aggregate carries a hosted ChildBinding whose childTBSHash is the SHA-256 of DSEP_LADDER || DER(tbs) of the child's current PQLO TBS (Section 5.4).¶
Omitting pqSignature does not make the PQLO an unsigned or malformed object: it remains a well-formed [RFC6488] signed object whose CMS signature is present and valid.
An RP authenticates a hosted child in two steps: it hashes the TBS it fetched and requires the matching childTBSHash in an already-authenticated parent aggregate, and it independently reconstructs the child's ladder from the child's own Manifest and objects and requires the reconstruction to equal the TBS's ladderRoot and rungDescriptors.
It never trusts the values in a hosted PQLO on their own.¶
Because one operator runs the entire hosted chain, it updates leaf-CA state, recomputes the affected childTBSHash values and aggregates bottom-up, and re-signs once, at the nearest ancestor holding a post-quantum key (the Trust Anchor, or a delegated intermediate CA).
The result is one post-quantum signature per coalesced batch of changes, regardless of how many hosted CAs changed in the batch.¶
In delegated mode the child operates its own CA, holds its own post-quantum key, and signs and publishes its own PQLO at its own publication point (Section 5.2).
The parent's aggregate carries a delegated ChildBinding whose childPQPublicKey is the child's post-quantum SubjectPublicKeyInfo, thereby authenticating the child's key; the child authenticates its own TBS with that key.
The parent's aggregate changes only when the child's key rolls or the child's CA certificate is reissued (childCertificateHash), fully decoupling parent and child update cadences: a delegated child refreshes its Manifest and PQLO with no parent interaction at all.
Carrying one FN-DSA-512 public key per delegated child adds on the order of 1 KB per child to the parent's PQLO.¶
How a delegated child conveys its post-quantum public key to its parent, and how the parent authenticates that conveyance, is an enrollment step of the existing parent-child relationship -- the same relationship over which the provisioning protocol [RFC6492] is established today. A protocol binding for this step (for example, an extension to RFC 6492) is out of scope for this document (Appendix "Open Issues for Working Group Review").¶
Authentication of any CA's PQLO proceeds upward until it terminates at a Trust Anchor whose post-quantum public key is preconfigured at the RP through the pqTAL (Section 8).
At each step the RP verifies one of two bindings.
For a Trust Anchor or a delegated CA, it verifies a pqSignature with a key it has already authenticated: the pqTAL key for a Trust Anchor, or the childPQPublicKey bound in the parent's aggregate for a delegated CA.
For a hosted CA, it requires the hash of the CA's TBS as the childTBSHash of a matching ChildBinding in the parent's aggregate.
The parent's aggregate is part of the parent's TBS and is authenticated the same way, recursively.
The chain of PQLOs mirrors the RPKI certificate hierarchy, and each PQLO is located from the corresponding CA certificate by the discovery rule of Section 5.2.
The complete procedure is specified in Section 11.¶
For a pqRPKI-aware CA, an RP derives object leaf indices and commitments from the Manifest it has validated for that CA, using the metadata separation and wire-order indexing of Section 4.3 and the verbatim-hash rule of Section 4.2. This document does not change the Manifest ASN.1 structure of [RFC9286].¶
To preserve object leaf indices when an object is removed or must not be published, a pqRPKI-aware CA MAY include placeholder entries in its Manifest fileList.
A placeholder is an ordinary FileAndHash entry that occupies the fileList slot of the entry it replaces, so wire-order indices (Section 4.3) are unchanged.
Its file uses a reserved, fileList-unique placeholder name (Section 7.3).
Its hash is the 32-octet commitment that was, or would be, at that leaf index.
Because the leaf index derives from the slot position and not from the file name, the placeholder name is free to differ from the name it replaces without perturbing any index.
Two placeholder name families are defined:¶
A pqRPKI-aware RP MUST NOT attempt to fetch a placeholder entry, MUST treat its hash as the object leaf commitment at that index, and MUST include it in ladder reconstruction.
Multiple deleted or hidden leaves within an epoch each keep a distinct placeholder entry in its original slot; because several deletions would otherwise collide on one reserved basename, each placeholder name MUST be unique within the fileList (Section 7.3).¶
[RFC9286] Section 4.2.2 constrains Manifest file names to one or more characters from [a-zA-Z0-9_-] followed by "." and a three-letter extension drawn from the IANA "RPKI Repository Name Schemes" registry.
This document updates that section to register and permit the pqRPKI file-name extension used by placeholder entries (and by the PQLO file, which shares the extension but is never listed), and to permit the two reserved placeholder basenames.
The concrete registry entries are in Section 15.¶
Deployments MUST use whatever extension IANA assigns (Section 15); throughout this document that extension is written ".pq" for readability. A placeholder file name is one of the two reserved-prefix families, a "D" (deleted) or "H" (hidden) followed by a fileList-unique decimal disambiguator, with this extension; editorially they are written "D<n>.pq" and "H<n>.pq" (for example "D1.pq", "D2.pq", "H1.pq"). The disambiguator carries no semantics beyond making the name unique within the fileList; a leaf's index comes from its slot (Section 4.3), never from the disambiguator. Formally a placeholder base name matches ("D" / "H") 1*DIGIT. The PQLO uses this extension with the base name of the CA's Manifest (Section 5.2) and is fetchable but never listed; a placeholder name is listed but never fetchable.¶
[RFC9286] Section 7 states that every published signed object in the RPKI is published at the publication point of the CA that issued its EE certificate and is listed in the Manifest associated with that CA certificate. This document creates one deliberate exception: the PQLO is published at the CA's publication point but is not listed on that CA's Manifest, nor on any other (Section 5.2). The exception is analogous to the Manifest itself, which RFC 9286 also requires to be published without any fileList naming it, and for the same reason: an object cannot carry the hash of a file whose content depends on that object.¶
RFC 9286 Section 6 anticipates this case. It requires that files not listed on a Manifest not be used to validate certificates, ROAs, and CRLs, and then provides that such files "MAY be employed to validate other signed objects, if the profile of the object type explicitly states that such behavior is allowed (or required)". This document is the profile of the PQLO and explicitly states it: a pqRPKI-aware RP MUST retrieve and validate a CA's PQLO by the discovery rule of Section 5.2, and MUST NOT treat the absence of a fileList entry for it as a reason to disregard it.¶
Manifest processing itself is unaffected. The acquisition and hash-verification rules of RFC 9286 Section 6 apply to files a Manifest lists, so a legacy RP neither fetches nor evaluates the PQLO. This document does not otherwise relax the property that RPKI objects an RP validates for routing purposes are enumerated by a Manifest: the PQLO carries no Internet Number Resources and makes no routing assertion, and ordinary RPKI validation disregards it entirely. RFC 9286 Section 6 cautions that relying on unlisted files may allow substitution attacks against them; the countermeasure here is that a PQLO's TBS is authenticated by the parent's aggregate or by the pqTAL key rather than by its presence at a location (Section 14).¶
[RFC9286] Section 6.4 requires that an RP acquire ALL files enumerated in the Manifest fileList and treat any listed file that cannot be retrieved as a failed fetch for the entire publication point. Under that rule alone, a placeholder entry (which has no fetchable object) would cause a conformant RP to fail the CA. This document updates RFC 9286 Section 6.4 as follows:¶
file matches a reserved pqRPKI placeholder name family (Section 7.3) is an index-preserving marker, not a repository object.
A conformant RP MUST NOT attempt to retrieve it and MUST NOT treat its absence from the repository as a failed fetch.
All other Section 6 processing (including hash checks for genuinely published files) is unchanged.¶
A pqRPKI-aware RP implements this exemption directly. A legacy RP that has not been updated to this document remains, by RFC 9286 Section 6.4, entitled to treat an unretrievable placeholder as a failed fetch. Therefore, in a public dual-stack deployment where legacy-RP compatibility is required, an issuer MUST NOT publish placeholder entries unless it has confirmed that the relevant legacy RP implementations tolerate them. A deployment can avoid placeholders entirely by rebuilding the ladder from the compacted fileList whenever an object is removed, at the cost of re-hashing the affected object rungs on every removal rather than only at planned boundaries. The PQLO itself never interacts with this rule: it is not listed on any Manifest (Section 5.2), so RFC 9286 fetch processing never considers it.¶
A Trust Anchor Locator (TAL, [RFC8630]) conveys exactly one subjectPublicKeyInfo and provides no field for a second key or an extension.
It therefore cannot, unmodified, distribute a Trust Anchor's post-quantum public key alongside its RSA key.
An RP validating pqRPKI MUST be configured with the authentic post-quantum public key of each Trust Anchor it recognizes.
This document defines a companion Post-Quantum Trust Anchor Locator (pqTAL) that a Trust Anchor operator publishes and distributes alongside its existing TAL:¶
SubjectPublicKeyInfo, using an algorithm identifier of Section 9.¶
The post-quantum public key in a pqTAL MUST be stable across Trust Anchor certificate reissuance for as long as that key authenticates the Trust Anchor's PQLO, and MUST match the key used to verify that PQLO's pqSignature.
Distribution and out-of-band verification of the pqTAL are subject to the same operational trust assumptions as the TAL ([RFC8630] Sections 2.1 and 5).
Whether the long-term mechanism is a companion pqTAL, an update to RFC 8630 permitting multiple keys, or a separate SIDROPS document, is an open question (Appendix "Open Issues for Working Group Review"); a companion file is specified here so the mechanism is complete and implementable.¶
The RPKI algorithm profile [RFC7935] mandates RSA-2048 with SHA-256 and provides no in-band algorithm negotiation; algorithm transitions in RPKI are performed by replacing the profile and following the transition procedure of [RFC6916].
pqRPKI does not alter [RFC7935] for existing RSA-authenticated objects.
Instead, it confines the post-quantum algorithm choice to the PQLO: the TBS names the hash algorithm (hashAlgorithm) and, when the CA signs its own PQLO, the signature algorithm (pqSignatureAlgorithm), while a delegated child's algorithm is carried self-descriptively in the SubjectPublicKeyInfo of its ChildBinding.
Algorithms can therefore differ, and roll, per CA.¶
The mandatory-to-implement post-quantum signature algorithm for this version is FN-DSA-512 (Falcon-512, [Falcon]), chosen for its compact public keys and signatures relative to other standardized options; standardization of FN-DSA as NIST FIPS 206 is in progress.
ML-DSA-65 ([FIPS204]) is defined as an additional permitted algorithm.
The object identifiers for these algorithms and their AlgorithmIdentifier parameter conventions are to be assigned and profiled in coordination with the RPKI algorithm profile and the PKIX/LAMPS post-quantum work (Section 15, Appendix "Open Issues for Working Group Review"); until an RPKI post-quantum algorithm profile exists, these identifiers are provisional.
The hashAlgorithm field is id-sha256 in this version.¶
A CA that supports pqRPKI MUST, for each publication point:¶
manifestHash.¶
ladderRoot per Section 4 using the algorithm named in hashAlgorithm, and populate rungDescriptors to match.¶
aggregateRoot per Section 6 and populate children: for each hosted child, the current childTBSHash; for each delegated child, its childPQPublicKey.¶
caKeyIdentifier, manifestHash, manifestNumber, thisUpdate, and nextUpdate equal the corresponding CA-certificate and Manifest values, and DER-encode the TBS.¶
pqSignatureAlgorithm and compute pqSignature over DSEP_LADDER || DER(PqRPKILadderTBS) (Section 5.4).
A hosted CA omits both fields; its operator instead feeds the new TBS hash into the parent aggregate (Section 6.1).¶
PqRPKILadder as an RFC 6488 signed object with a fresh one-time-use EE certificate issued by this CA, name the file after the CA's Manifest with the pqRPKI extension (Section 5.2), and publish it at this CA's publication point.¶
thisUpdate/nextUpdate/manifestNumber MUST track that Manifest ([RFC9981]).¶
Within a hosted chain, the operator propagates childTBSHash updates bottom-up and re-signs once per coalesced batch at the nearest ancestor holding a post-quantum key.
A parent MUST update its aggregate whenever a hosted child's TBS changes, a delegated child's key rolls, or a bound child certificate changes.
A Trust Anchor signs with the post-quantum key published in its pqTAL (Section 8).¶
An upgraded RP MUST first perform ordinary RPKI validation (certificate path, Manifest, CRL, and signed objects). pqRPKI never makes an otherwise-invalid RPKI object valid; it is an additional authentication check over already-valid repository state.¶
pqRPKI authentication proceeds top-down, so that no value is used before it has been authenticated. An RP starts at each Trust Anchor for which it holds a pqTAL, authenticates that Trust Anchor's TBS with the preconfigured post-quantum key, and then descends: a CA C below a Trust Anchor is authenticated only after C's parent's TBS has been authenticated, using the aggregate carried in that already-authenticated parent TBS. An RP MUST perform the checks of step 5 below and the authentication of the parent over the identical octets of a single fetched parent PQLO. For each CA C reached this way, the RP MUST:¶
rpkiManifest SIA accessLocation (Section 5.2) -- or, for a Trust Anchor, use the pqTAL URIs -- and fetch it.
If no valid PQLO can be obtained, pqRPKI validation of C fails (see below).
Validate the PQLO as an RFC 6488 signed object, including its EE-certificate path and CRL check.¶
caKeyIdentifier, manifestHash, manifestNumber, thisUpdate, and nextUpdate match the validated CA certificate and the Manifest state selected by [RFC9286] processing.
An RP SHOULD cache a CA's Manifest and PQLO as one unit, so that when RFC 9286 processing falls back to a previously validated Manifest state, the PQLO retained with that state is used.¶
manifestHash verified in the previous step.¶
ladderRoot and rung roots equal the PQLO's ladderRoot and rungDescriptors.
If the PQLO carries an aggregate, recompute aggregateRoot from children (Section 6) and verify it equals the carried value.¶
Authenticate C's TBS against the already-authenticated parent:¶
pqSignature, obtain C's post-quantum public key from its authenticated source.
For a Trust Anchor, that source is the preconfigured pqTAL key (Section 8).
Otherwise it is the childPQPublicKey of the delegated ChildBinding for C in the parent's aggregate, whose childKeyIdentifier and childCertificateHash MUST match C's validated CA certificate.
Verify pqSignature over DSEP_LADDER || DER(tbs) with that key.
The ChildBinding's childMode MUST be delegated.¶
pqSignature (hosted), compute SHA-256 of DSEP_LADDER || DER(tbs); there MUST be a hosted ChildBinding for C in the parent's aggregate whose childTBSHash equals that value and whose childKeyIdentifier and childCertificateHash match C's validated CA certificate.
The ChildBinding's childMode MUST be hosted.¶
The parent is the CA that issued C's certificate, and its PQLO is located by the discovery rule of Section 5.2; by the top-down order above, its TBS has already been authenticated when this step runs, and the RP MUST use those same octets here. Where a CA holds valid certificates from more than one parent, pqRPKI validation is performed per certificate path.¶
pqRPKI awareness MUST form a contiguous subtree rooted at a Trust Anchor for which the RP holds a pqTAL. If any ancestor of C on the certificate path to that Trust Anchor lacks a PQLO, or lacks a ChildBinding for its child on that path, then no authenticated pqRPKI path to C exists and pqRPKI validation of C fails.¶
An RP MAY use authenticated ladder and aggregate roots for top-down synchronization.
Comparing a parent's aggregateRoot against cache identifies which children changed without fetching unchanged children's Manifests; comparing a CA's ladderRoot against cache identifies whether any object changed; and comparing the Manifest FileAndHash sequence against cache localizes exactly which objects to fetch.
The RP then fetches only missing or changed files and recomputes only the affected leaves and internal nodes.
This is compatible with RRDP [RFC8182] and with hash-comparison synchronization such as the Erik protocol [I-D.ietf-sidrops-rpki-erik-protocol], which can reuse the Manifest H0[i] commitments directly.¶
If ordinary RPKI validation succeeds but pqRPKI validation fails (including a missing or stale PQLO at a pqRPKI-aware CA), an RP in dual-stack mode SHOULD report the pqRPKI failure and MAY continue emitting payloads from ordinary RPKI validation per local policy (Section 12.1). An RP in post-quantum-required mode MUST treat pqRPKI validation failure as failure of the affected CA subtree (Section 12.2).¶
CAs publish existing RSA-authenticated objects unchanged and additionally publish PQLOs; the Manifest continues to carry all legacy fields. Legacy RPs are unaffected by the PQLO itself, which no Manifest lists; placeholder entries do affect them, and an issuer publishing placeholders is subject to the constraint of Section 7.5. Upgraded RPs validate pqRPKI in parallel and can report discrepancies before operators rely on pqRPKI for routing decisions. Reusing the Manifest's SHA-256 hashes as leaf commitments means the added post-quantum authentication data is a small, fixed per-CA overhead (the PQLO, including any aggregate) rather than per-object growth.¶
In post-quantum-required mode, an RP treats pqRPKI validation failure as validation failure for the affected CA subtree. An RP in this mode MUST also treat a CA for which no authenticated pqRPKI path to a configured pqTAL exists as a validation failure for that CA's subtree: absence of pqRPKI awareness is a failure in this mode, not an exemption. Without this rule, suppressing the evidence that a CA is pqRPKI-aware would silently return that subtree to RSA-only authority (Section 14). This mode is for a later phase, after publication points, RPs, and trust-anchor material are upgraded. A CA can at that point stop relying on RSA and let pqRPKI authenticate the existing object bytes; the post-quantum authentication of the TBS binds the freshness fields with no RSA fallback (Section 5.4). The object profile for operating entirely without RSA material -- including the CMS envelope of the PQLO itself -- is not defined by this document (Appendix "Open Issues for Working Group Review").¶
pqRPKI does not change the RP-to-router protocol or the payload format. Routers consume RP output as they do today.¶
Because a PQLO is reissued with every Manifest reissue, implementations SHOULD apply the Manifest-number guidance of [RFC9981] and avoid unnecessary high-frequency Manifest reissuance.
On a change of Manifest file name, the RFC 9981 rules for resetting the stored Manifest number apply equally to the PQLO's manifestNumber, and the PQLO's file name follows the Manifest's (Section 5.2).¶
In a fully hosted registry, every coalesced batch of hosted-CA changes results in one post-quantum signature by the Trust Anchor key, giving that key an online signing cadence comparable to the Trust Anchor's existing Manifest and CRL reissuance. A registry that prefers to keep its Trust Anchor post-quantum key offline SHOULD operate its production intermediate CA as a delegated pqRPKI child: the Trust Anchor's aggregate then binds only that CA's stable public key, and the Trust Anchor key signs only on its own Manifest cadence and at production-key rollover.¶
An aggregate carries one ChildBinding per pqRPKI-aware child. At a registry with tens of thousands of hosted member CAs, the parent PQLO grows to megabytes and changes with each batch. RRDP deltas do not soften this: [RFC8182] delta files carry complete replacement objects rather than byte-level differences, so a single-child change republishes the entire aggregate to every RP. Republication volume therefore scales with aggregate size multiplied by batch rate and RP population, and an adversary able to induce frequent hosted-child changes amplifies load across the whole RP population. Whether very large registries need per-child authentication paths instead of the full child list is an open issue (Appendix "Open Issues for Working Group Review").¶
RPs SHOULD cache reconstructed ladder and aggregate nodes and reconstruct each internal node at most once per validation cycle; reusing internal nodes across a CA's objects is a principal efficiency benefit over per-object authentication paths. The depth-0 metadata rungs make routine Manifest and CRL refreshes O(1) in ladder work.¶
Deleted-leaf placeholders accumulate within a signing epoch and are cleared at the next reindexing (typically a daily rebuild); their storage overhead is bounded and small relative to repository size, but CAs SHOULD rate-limit revocation bursts and MAY cap the number of retained placeholders per rebuild window. Publication services SHOULD present a coherent fetch view of all files in a CA update; the guidance of [I-D.ietf-sidrops-publication-server-bcp] applies.¶
Rung sizes are not configurable; they follow from the object-leaf count (Section 4.4). What an issuer controls is the signing-epoch length and compaction cadence, which trade rebuild cost against placeholder accumulation. Operators SHOULD monitor PQLO issuance rate and PQLO/Manifest consistency.¶
pqRPKI adds post-quantum authentication to RPKI repository state; it does not replace ordinary RPKI certificate, Manifest, CRL, or signed-object validation. An RP MUST NOT accept an otherwise-invalid RPKI object solely because it appears in a valid CA Ladder. Every object remains independently validatable via the CA certificate and the Manifest, which carries all leaf commitments; a missing or withheld leaf does not create an attack on other objects.¶
What the post-quantum layer covers. Authenticating a TBS -- by a Trust Anchor or delegated CA signature, or by a hosted childTBSHash binding -- transitively authenticates the CA's complete published state.
Via ladderRoot, it covers the Manifest ordering and every object commitment H0[i].
Via manifestHash and the metadata rungs, it covers the current Manifest and CRL.
Via the freshness fields, it covers the epoch.
Via aggregateRoot and children, it covers each child's entire TBS (hosted) or public key (delegated).
Because the full TBS is covered -- including any aggregate -- these bindings hold recursively for arbitrarily deep hosted chains, and they hold even in post-quantum-required mode where the RSA CMS signature is no longer relied upon.¶
Domain separation and key reuse. The four domain-separation tags separate every tagged construction step, so a hash produced for one such step cannot be reinterpreted as another.
Object leaves are deliberately untagged; see below.
DSEP_LADDER prefixes the TBS bytes both when they are signed (Trust Anchor, delegated CA) and when they are hashed into a hosted childTBSHash; in both cases the authenticated semantics are the same TBS, so no cross-interpretation arises, while the prefix separates these bytes from any other use of the same post-quantum key.
Implementations MUST NOT reuse a pqRPKI signing key for unrelated MTL instantiations or protocols, and MUST protect signer state against rollback and against reusing stale ladder state across epochs.¶
Replay and rollback. pqRPKI authenticates, but does not refresh, the RPKI freshness fields; it adds no replay defense of its own.
A (Manifest, PQLO) pair remains internally consistent and post-quantum valid until nextUpdate, so an adversary able to serve stale repository content -- a publication point, a mirror or cache, or an on-path attacker where rsync or non-post-quantum TLS is in use -- can replay that pair for the remainder of its validity interval.
Transport integrity does not prevent this: [RFC8182] Section 4.3 observes that an on-path attacker cannot produce validly signed RPKI data but can still perform withhold and replay attacks.
Within the validity window the defenses are those of [RFC9286] and [RFC9981]: the thisUpdate/nextUpdate interval, which pqRPKI binds into the TBS and which therefore cannot be extended without the authenticating post-quantum key, and relying-party retention of the highest manifestNumber observed per CA.
The latter is relying-party local state: it is unavailable at first contact or after a cache reset, and RFC 9981 requires it to be reset when a CA changes its Manifest file name.
RPs SHOULD persist per-CA manifestNumber state across restarts and SHOULD report any decrease.
A hosted child's parent aggregate does constrain rollback, because a current parent PQLO pins the child's exact current TBS hash (Section 10); a delegated child's parent binds only a long-lived public key, so a delegated subtree has no cross-CA freshness coupling.
Retaining the commitment of a deleted leaf under a D placeholder does not enlarge this surface.
A stale object is rejected because its file name no longer appears in the current fileList.
The retained commitment sits at a placeholder name an RP never fetches (Section 7.5), and revocation is signalled on the CRL, which is bound into the same ladder.¶
Withholding and downgrade. The PQLO is not listed on any Manifest, so ordinary Manifest processing does not notice its absence; an adversary controlling transport or a publication point can strip it. Stripping a PQLO is detectable by an upgraded RP that holds an authenticated ancestor assertion for that CA: pqRPKI-awareness is asserted post-quantum authentically above the CA, through a ChildBinding in the parent's aggregate or through the pqTAL for a Trust Anchor. A missing, stale, or mismatching PQLO at a pqRPKI-aware CA is therefore a pqRPKI validation failure, handled per migration mode (Section 12): reported, and by local policy tolerated, in dual-stack mode; fatal for the subtree in post-quantum-required mode.¶
The residual attack is therefore not to make a CA fail but to make an RP believe the CA was never pqRPKI-aware.
An adversary who can serve an RP a stale but still-valid ancestor PQLO issued before the CA was added to that ancestor's aggregate suppresses the awareness assertion itself.
Two rules bound this: pqRPKI awareness MUST form a contiguous subtree rooted at a configured pqTAL (Section 11), and in post-quantum-required mode a CA with no authenticated pqRPKI path to a pqTAL fails (Section 12.2), so the adversary must suppress awareness for an entire subtree up to a Trust Anchor rather than for one CA.
Beyond that, the defence is the replay bound above: per-CA manifestNumber retention and the ancestor's nextUpdate.
As in any dual-stack cryptographic migration, protection against a quantum-capable adversary begins when RPs enforce post-quantum-required mode.¶
Untagged object leaves. Object-leaf commitments are Manifest hashes used verbatim, with no leaf-level domain-separation tag (Section 4.2), and a rung of size 1 has a rung root equal to its leaf (Section 4.4).
Leaf commitments and internal-node values are therefore drawn from the same 32-octet space and are not distinguishable by value.
A repository object whose file content is exactly 80 octets of the form DSEP_NODE || L || R has a Manifest hash equal to the internal-node value node(L, R).
A placeholder entry (Section 7.2) may carry any 32-octet value at all, since it corresponds to no file and is exempt from fetch and hash checking (Section 7.5).¶
This is safe for the procedure of Section 11 for a reason stronger than domain separation.
manifestHash is SHA-256 over the entire Manifest eContent and therefore already binds every file name, every leaf commitment, and their exact order.
ladderRoot is a deterministic function of data that manifestHash already authenticates, and the leaf count K is folded into the ladder-root reduction.
pqRPKI carries no per-object authentication paths, so no verification step infers a value's position in the tree from the value itself.
An RP performing the full reconstruction of Section 11 cannot be induced to accept a leaf as a subtree or a subtree as a leaf.¶
That guarantee is conditional on full reconstruction. An RP using the incremental and cached-node optimizations permitted by Section 11 and Section 13 MUST ensure the optimization is equivalent to full reconstruction. Cached ladder and aggregate nodes MUST be keyed by position: the CA, the ladder or aggregate, the rung index, the level, and the offset within the level. They MUST NOT be keyed by node value alone, and MUST NOT be reused at any other position. An implementation that memoizes verified subtrees by value is vulnerable, because a CA controls the 32-octet commitments in its own fileList, including placeholder commitments that correspond to no published file.¶
Hash strength. pqRPKI's collision and second-preimage security rest on the leaf/node hash, SHA-256, reused from the Manifest.
SHA-256 provides 128-bit collision resistance, which bounds the post-quantum security level of the ladder authentication irrespective of the signature algorithm's strength.
If a deployment requires a larger long-term margin, a future profile can substitute a stronger hash via the hashAlgorithm field; this would also require the Manifest hash algorithm to change, since the leaf commitments are the Manifest hashes (Appendix "Open Issues for Working Group Review").¶
Trust anchor dependency. pqRPKI's guarantees reduce to the authenticity of the preconfigured Trust Anchor post-quantum keys (Section 8). Distribution and out-of-band verification of the pqTAL are as security-critical as the TAL and share its trust model; a compromised or substituted pqTAL key defeats pqRPKI for that Trust Anchor.¶
New cross-CA dependency. In today's RPKI a stale or unfetchable parent Manifest does not invalidate a child's objects.
Under pqRPKI a hosted CA's validity depends on its parent's PQLO carrying a childTBSHash matching that CA's current TBS (Section 6.1), so in post-quantum-required mode an adversary who can stall, strip, or stale a single PQLO invalidates every hosted descendant beneath it -- at a large registry, potentially its entire membership.
The set of entities that can affect a CA's subtree therefore now includes those who can affect its ancestors' publication points and transport paths.
The same coupling produces a benign race: nothing orders a child's repository update against its parent's, so during a hosted batch an RP can observe a new child (Manifest, PQLO) against an old parent PQLO.
Within a hosted batch an operator SHOULD publish ancestor PQLOs after descendant PQLOs; an RP encountering a childTBSHash mismatch SHOULD re-fetch the parent's PQLO before declaring failure, and MAY apply a bounded grace interval before failing a subtree in post-quantum-required mode.
Any such grace interval is a deliberate rollback-versus-availability trade-off.¶
Out of scope. pqRPKI authenticates repository content after retrieval. It does not by itself provide post-quantum protection for the transport and naming layers (for example, RRDP over HTTPS, or publication-point host naming via DNSSEC); those require their own post-quantum migrations and are orthogonal to this document. pqRPKI does not change the RPKI trust model or an adversarial publication point's existing (unchanged) ability to withhold or stall its own content; it does add the cross-CA dependency described above.¶
IANA is requested to assign an object identifier for id-ct-pqrpkiLadder in the "SMI Security for S/MIME CMS Content Type (1.2.840.113549.1.9.16.1)" registry, referencing this document, and to record the eContentType in the RPKI-relevant signed-object listing analogous to existing RPKI signed objects.¶
IANA is requested to assign an object identifier for id-mod-pqrpki-2026 in the "SMI Security for S/MIME Module Identifier (1.2.840.113549.1.9.16.0)" registry, referencing this document.¶
IANA is requested to register the pqRPKI file-name extension in the "RPKI Repository Name Schemes" registry (created by [RFC6481]), with this document as the reference. If the registry's three-letter constraint is retained, a three-letter extension is required; the value ".pq" used editorially in this document is a placeholder pending that assignment (Appendix "Open Issues for Working Group Review"). The registration MUST also reserve the two placeholder basename families ("D" and "H" followed by digits, with the assigned extension) as non-fetchable index-preserving markers per Section 7.5.¶
IANA is requested to register the media type application/rpki-pqlo for the PQLO, following the RPKI signed-object media-type template.¶
Object identifiers and AlgorithmIdentifier parameter conventions for FN-DSA-512 and ML-DSA-65, as used in the PQLO pqSignatureAlgorithm field and in childPQPublicKey, are to be assigned in coordination with the applicable PKIX/LAMPS and RPKI algorithm-profile work.
This document does not itself allocate these values (Appendix "Open Issues for Working Group Review").¶
This section is to be removed before publication. The core cryptographic construction of Section 4 (the domain-separated leaves, rungs, and ladder root) has been implemented in a signer and in a relying party that reconstructs ladders and verifies FN-DSA-512 signatures; the two interoperate at the byte level against a shared set of leaf/rung/ladder test vectors. An operational trial under a production Regional Internet Registry confirmed that current unmodified relying parties validate the accompanying legacy objects without error.¶
The prototype predates parts of this specification. It conveys the ladder root in an X.509 certificate extension on the CA certificate rather than in the PQLO signed object of Section 5. It does not implement the placeholder entries of Section 7.2, and it predates the trust-chain encoding of Section 6 (hosted TBS-hash bindings and per-child SubjectPublicKeyInfo). The PQLO encoding, discovery rule, and placeholder processing are therefore normatively defined by this document but have not yet been exercised for byte-level interoperability.¶
The authors thank the members of the SIDROPS Working Group for discussions of this work at IETF 123, IETF 124, and IETF 125.¶
rpkiManifest SIA accessLocation by substituting the extension (Section 5.2).
Alternatives are a new SIA accessMethod on the CA certificate (which RFC 6487 profile strictness may not admit) or listing the PQLO on a Manifest, which was rejected: listing on the CA's own Manifest is circular, and listing on the parent's Manifest couples every child Manifest refresh to reissues at every ancestor.
Confirm the derived-name rule.¶
manifestHash) and requires issuers to hold fileList slots stable within an epoch (Section 4.3).
An alternative is an explicit per-leaf index field in the PQLO, which removes the stable-slot requirement at the cost of re-listing leaves; confirm the preferred approach.¶
manifestNumber, thisUpdate, and nextUpdate over different aggregates, so an RP cannot order them.
The candidate fixes are a monotonic pqloNumber field in the TBS with RFC 9981-style handling, or requiring a parent to reissue its Manifest whenever its aggregate changes.
This is the most significant open design question in this document.¶
childCertificateHash.
Confirm whether to add a self caCertificateHash and to pair the pqTAL cryptographically with the TAL.¶