SIDROPS W. Li Internet-Draft T. Chung Updates: 9286 (if approved) Virginia Tech Intended status: Standards Track 20 July 2026 Expires: 21 January 2027 Post-Quantum Authentication for the Resource Public Key Infrastructure draft-li-sidrops-pqrpki-00 Abstract 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. Status of This Memo 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/. Li & Chung Expires 21 January 2027 [Page 1] Internet-Draft pqRPKI July 2026 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 Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Relationship to Other Post-Quantum RPKI Work . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Design Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Manifest-Centered Authentication . . . . . . . . . . . . 7 3.2. Ladders, Rungs, and Metadata Rungs . . . . . . . . . . . 8 3.3. Per-CA Ladders, Aggregation, and Update Decoupling . . . 8 3.4. Design Goals . . . . . . . . . . . . . . . . . . . . . . 9 4. Cryptographic Construction . . . . . . . . . . . . . . . . . 10 4.1. Domain-Separation Tags . . . . . . . . . . . . . . . . . 10 4.2. Object Leaf Commitments . . . . . . . . . . . . . . . . . 11 4.3. Leaf Order, Indexing, and Exclusions . . . . . . . . . . 11 4.4. Rungs and Rung Roots . . . . . . . . . . . . . . . . . . 12 4.5. Metadata Rungs . . . . . . . . . . . . . . . . . . . . . 13 4.6. Ladder Root . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Worked Example (K = 14 object leaves) . . . . . . . . . . 14 5. The pqRPKI Ladder Object (PQLO) . . . . . . . . . . . . . . . 14 5.1. Signed-Object Profile . . . . . . . . . . . . . . . . . . 14 5.2. Publication, Naming, and Discovery . . . . . . . . . . . 15 5.3. ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Post-Quantum Signing Input . . . . . . . . . . . . . . . 20 6. Aggregation and Delegation . . . . . . . . . . . . . . . . . 20 6.1. Hosted Mode . . . . . . . . . . . . . . . . . . . . . . . 22 6.2. Delegated Mode . . . . . . . . . . . . . . . . . . . . . 22 Li & Chung Expires 21 January 2027 [Page 2] Internet-Draft pqRPKI July 2026 6.3. Trust Chain . . . . . . . . . . . . . . . . . . . . . . . 23 7. Manifest Use and Updates to RFC 9286 . . . . . . . . . . . . 23 7.1. Deriving Leaf Indices and Commitments . . . . . . . . . . 23 7.2. Placeholder Entries . . . . . . . . . . . . . . . . . . . 23 7.3. Update to RFC 9286: File-Name Extension . . . . . . . . . 24 7.4. Update to RFC 9286: Publication of Unlisted Ladder Objects . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.5. Update to RFC 9286: Placeholder Fetch Semantics . . . . . 25 8. Post-Quantum Trust Anchor Distribution . . . . . . . . . . . 26 9. Algorithm Profile and Agility . . . . . . . . . . . . . . . . 27 10. Issuer Behavior . . . . . . . . . . . . . . . . . . . . . . . 27 11. Relying Party Behavior . . . . . . . . . . . . . . . . . . . 29 12. Migration Modes . . . . . . . . . . . . . . . . . . . . . . . 31 12.1. Dual-Stack Mode . . . . . . . . . . . . . . . . . . . . 31 12.2. Post-Quantum-Required Mode . . . . . . . . . . . . . . . 31 12.3. Router Interface . . . . . . . . . . . . . . . . . . . . 32 13. Operational Considerations . . . . . . . . . . . . . . . . . 32 14. Security Considerations . . . . . . . . . . . . . . . . . . . 33 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 15.1. SMI Security for S/MIME CMS Content Type . . . . . . . . 37 15.2. SMI Security for S/MIME Module Identifier . . . . . . . 37 15.3. RPKI Repository Name Scheme . . . . . . . . . . . . . . 37 15.4. Media Type . . . . . . . . . . . . . . . . . . . . . . . 38 15.5. Post-Quantum Algorithm Identifiers . . . . . . . . . . . 38 16. Normative References . . . . . . . . . . . . . . . . . . . . 38 17. Informative References . . . . . . . . . . . . . . . . . . . 39 Implementation Status . . . . . . . . . . . . . . . . . . . . . . 41 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 41 Open Issues for Working Group Review . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 1. Introduction 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 Li & Chung Expires 21 January 2027 [Page 3] Internet-Draft pqRPKI July 2026 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: * RPKI repositories contain many objects (CA certificates, CRLs, Manifests, and large numbers of signed routing-policy objects); any per-object size increase is multiplied across the complete global repository. * RPs repeatedly synchronize and validate complete repositories, so a larger object format affects every validation cycle, not only occasional certificate-issuance events. * Manifests and CRLs are refreshed far more frequently than routing objects; a design that couples routine metadata refreshes to broad object re-signing would greatly increase publication-point churn and RP work. * Deployment must support a long transition in which upgraded and non-upgraded RPs coexist; a flag-day replacement of today's RSA- authenticated objects is not operationally realistic. 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. Li & Chung Expires 21 January 2027 [Page 4] Internet-Draft pqRPKI July 2026 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. 1.1. Relationship to Other Post-Quantum RPKI Work Post-quantum migration of the RPKI has two largely independent dimensions: which algorithm produces each signature, and how many objects one signature covers. [I-D.yoshikawa-sidrops-pqc-rpki] addresses the first, profiling a composite post-quantum suite for RPKI certificates, CRLs, certification requests, and CMS signed objects, introduced at CA boundaries and retaining today's one- signature-per-object model. This document addresses the second: it leaves the signature on each existing object untouched and adds one post-quantum signature per CA over that CA's complete published state, so the number of post-quantum signatures an RP verifies scales with the number of CAs rather than the number of objects. The two are therefore complementary rather than alternatives and can be deployed together. Which combination is appropriate, and in which order the two are deployed, is a question for the Working Group. 1.2. Requirements Language 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. 2. Terminology This document uses the RPKI terminology of [RFC6480], [RFC6487], [RFC6488], and [RFC9286]. It additionally defines: Li & Chung Expires 21 January 2027 [Page 5] Internet-Draft pqRPKI July 2026 CA Ladder The Merkle Tree Ladder that authenticates the complete set of files published by a single RPKI CA at its publication point during one signing epoch. Object leaf A depth-0 ladder leaf corresponding to an ordinary published object (for example, a ROA or a subordinate certificate) or to a placeholder entry (Section 7.2). Metadata leaf / metadata rung A depth-0 single-leaf rung appended after all object rungs, used to represent the frequently reissued Manifest and CRL without perturbing object-leaf indices (Section 4.5). Leaf index The zero-based position of an object leaf in the Manifest fileList wire order, after removing the CRL entry (Section 4.3). Because the exact Manifest byte order is authenticated by the signed manifestHash, this position is itself authenticated; no separate index field is carried. Leaf commitment The depth-0 value H0[i] committed to leaf index i. For object leaves derived from a Manifest, it is the file's SHA-256 hash as it already appears in the Manifest FileAndHash entry (Section 4.2). Rung A perfect (fully balanced) binary Merkle tree over a power-of- two run of consecutive leaves. A CA Ladder is a sequence of rungs (Section 4.4). Rung root / ladder root The root of an individual rung; and the single value that binds all rung roots of a ladder (Section 4.6). PQLO The pqRPKI Ladder Object defined in Section 5: an RFC 6488 signed object, published at the authenticated CA's own publication point but never listed on any Manifest, carrying that CA's ladder root, rung descriptors, Manifest binding, optional aggregate, and (for a Trust Anchor or delegated CA) post-quantum signature. pqRPKI-aware CA A CA that is bound, as a hosted or delegated child, in its parent's aggregate (Section 6), or a Trust Anchor for which a pqTAL is configured. A pqRPKI-aware CA MUST publish a PQLO. Aggregate A ladder, carried in a parent CA's PQLO, whose leaves bind the parent's pqRPKI-aware child CAs: a hash of the child's PQLO TBS for a hosted child, or the child's post-quantum public key for a delegated child (Section 6). Hosted child (pqRPKI) A pqRPKI-aware CA that holds no post-quantum Li & Chung Expires 21 January 2027 [Page 6] Internet-Draft pqRPKI July 2026 key of its own; its PQLO carries no post-quantum signature and its TBS is authenticated through the parent's aggregate (Section 6.1). This typically coincides with hosted RPKI operation, in which the parent registry operates the CA. Delegated child (pqRPKI) A pqRPKI-aware CA that holds its own post- quantum key and signs its own PQLO; the parent's aggregate binds only that key (Section 6.2). pqTAL The Post-Quantum Trust Anchor Locator of Section 8: an out-of- band file, distributed like a TAL, that conveys a Trust Anchor's post-quantum public key and the location of its PQLO. Placeholder entry A Manifest FileAndHash entry with a reserved, unique deleted (D) or hidden (H) file name that occupies a fixed fileList slot and whose retained hash preserves a leaf index without a fetchable object (Section 7.2). Signing epoch The interval between two rebuilds of a CA Ladder that reassign object leaf indices (typically bounded by CA key rollover or a planned compaction), during which the issuer holds fileList slots stable (appending new leaves and replacing removed leaves in place with placeholders) so leaf indices do not shift. 3. Design Overview 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). 3.1. Manifest-Centered Authentication 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 Li & Chung Expires 21 January 2027 [Page 7] Internet-Draft pqRPKI July 2026 ordinary objects (ROAs, ASPAs, certificates, CRLs) are unchanged on the wire. 3.2. Ladders, Rungs, and Metadata Rungs 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. 3.3. Per-CA Ladders, Aggregation, and Update Decoupling 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. Li & Chung Expires 21 January 2027 [Page 8] Internet-Draft pqRPKI July 2026 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 Figure 1: pqRPKI Trust and Validation Flow 3.4. Design Goals Post-quantum authentication Authenticate CA repository state with a post-quantum signature whose cost is amortized across many objects. Object compatibility Preserve existing RPKI object encodings so ordinary validation remains available throughout migration. Manifest-centered verification Reuse the Manifest file-list order and SHA-256 hashes as the leaf index and leaf commitment source; add no per-object authentication paths. Efficient bulk validation Let RPs reconstruct each shared internal node at most once per cycle and reuse it across objects. Localized updates Support object addition, deletion, revocation, and Manifest/CRL refresh without reissuing unrelated objects or reindexing leaves. For a delegated CA this extends to independence from ancestors: no ancestor's publication point is touched. For a hosted CA, changes propagate upward to the nearest ancestor holding a post-quantum key (Section 6.1). Incremental deployment Allow publication points and RPs to upgrade independently, with an RSA fallback during dual-stack operation. Li & Chung Expires 21 January 2027 [Page 9] Internet-Draft pqRPKI July 2026 4. Cryptographic Construction 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. 4.1. Domain-Separation Tags 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 | +-------------+--------------------------+-------------------------+ Table 1: Domain-Separation Tags (16 octets each) 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). Li & Chung Expires 21 January 2027 [Page 10] Internet-Draft pqRPKI July 2026 4.2. Object Leaf Commitments 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. 4.3. Leaf Order, Indexing, and Exclusions 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: 1. The entry naming the CRL is removed from the object-leaf sequence and retained as the CRL metadata leaf (Section 4.5). The Manifest does not list itself ([RFC9286]); its metadata leaf value is defined in Section 4.5. 2. Every remaining entry -- ordinary objects (ROAs, ASPAs, subordinate CA certificates, ...) and placeholder entries (Section 7.2) alike -- is an object leaf. Its leaf index is its zero-based position in this filtered sequence. 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 Li & Chung Expires 21 January 2027 [Page 11] Internet-Draft pqRPKI July 2026 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). 4.4. Rungs and Rung Roots 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 Li & Chung Expires 21 January 2027 [Page 12] Internet-Draft pqRPKI July 2026 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. 4.5. Metadata Rungs After the object rungs, a CA Ladder appends exactly two single-leaf, depth-0 metadata rungs, in this order: 1. the _CRL rung_, whose rung root is the CRL metadata leaf: the 32-octet SHA-256 hash carried in the CRL's Manifest FileAndHash entry (equivalently, SHA-256 of the published CRL file); and 2. the _Manifest rung_, whose rung root is the Manifest metadata leaf: SHA-256 of the DER-encoded Manifest eContent ([RFC9286]). Because the Manifest never lists itself, this value is not taken from the fileList; it is the same value carried in the PQLO 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. 4.6. Ladder Root 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 Li & Chung Expires 21 January 2027 [Page 13] Internet-Draft pqRPKI July 2026 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. 4.7. Worked Example (K = 14 object leaves) 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"). 5. The pqRPKI Ladder Object (PQLO) 5.1. Signed-Object Profile 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. Li & Chung Expires 21 January 2027 [Page 14] Internet-Draft pqRPKI July 2026 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). 5.2. Publication, Naming, and Discovery 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 Li & Chung Expires 21 January 2027 [Page 15] Internet-Draft pqRPKI July 2026 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). 5.3. ASN.1 Module 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) } Li & Chung Expires 21 January 2027 [Page 16] Internet-Draft pqRPKI July 2026 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, Li & Chung Expires 21 January 2027 [Page 17] Internet-Draft pqRPKI July 2026 -- >= 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): version MUST be 0 for this specification. caKeyIdentifier MUST equal the SubjectKeyIdentifier of the CA Li & Chung Expires 21 January 2027 [Page 18] Internet-Draft pqRPKI July 2026 certificate whose publication point this PQLO authenticates (the 160-bit SHA-1 of the CA's subjectPublicKey BIT STRING, [RFC6487]). manifestHash MUST equal SHA-256 of the DER-encoded eContent of the CA's current Manifest, and MUST equal the Manifest metadata leaf R_mft (Section 4.5). Because it covers the Manifest's exact byte order, it authenticates every leaf index (Section 4.3). manifestNumber, thisUpdate, nextUpdate MUST equal the corresponding fields of the current Manifest; see [RFC9286] and [RFC9981]. hashAlgorithm MUST be id-sha256 in this version. pqSignatureAlgorithm MUST be present if and only if the outer 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. ladderRoot MUST equal the value computed in Section 4.6. rungDescriptors MUST describe, in ladder order, the object rungs followed by the CRL metadata rung and the Manifest metadata rung. Each descriptor'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. aggregate Present if and only if the CA has pqRPKI-aware children (Section 6). children MUST be sorted by increasing 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. Li & Chung Expires 21 January 2027 [Page 19] Internet-Draft pqRPKI July 2026 5.4. Post-Quantum Signing Input 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. 6. Aggregation and Delegation 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: Li & Chung Expires 21 January 2027 [Page 20] Internet-Draft pqRPKI July 2026 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. Li & Chung Expires 21 January 2027 [Page 21] Internet-Draft pqRPKI July 2026 6.1. Hosted Mode 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. 6.2. Delegated Mode 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 Li & Chung Expires 21 January 2027 [Page 22] Internet-Draft pqRPKI July 2026 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"). 6.3. Trust Chain 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. 7. Manifest Use and Updates to RFC 9286 7.1. Deriving Leaf Indices and Commitments 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]. 7.2. Placeholder Entries 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: Deleted (D) The object is no longer published, but its prior leaf Li & Chung Expires 21 January 2027 [Page 23] Internet-Draft pqRPKI July 2026 commitment is retained so indices and the ladder reconstruct unchanged for the remainder of the signing epoch. Deletion of an object that had an EE certificate MUST also be reflected by revocation on the CRL; a placeholder does not by itself revoke anything. Hidden (H) The artifact is intentionally not published (for example, an RPKI Signed Checklist [RFC9323] held privately), but its commitment is retained so the ladder reconstructs and public leaves verify without revealing the hidden file name or content. 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). 7.3. Update to RFC 9286: File-Name Extension [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.pq" and "H.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. Li & Chung Expires 21 January 2027 [Page 24] Internet-Draft pqRPKI July 2026 7.4. Update to RFC 9286: Publication of Unlisted Ladder Objects [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). 7.5. Update to RFC 9286: Placeholder Fetch Semantics [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: Li & Chung Expires 21 January 2027 [Page 25] Internet-Draft pqRPKI July 2026 * A Manifest fileList entry whose 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. 8. Post-Quantum Trust Anchor Distribution 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: * an optional comment section, as in RFC 8630 Section 2.2; * a URI section: one or more URIs (rsync or HTTPS) at which the Trust Anchor's PQLO can be retrieved, one per line. These URIs point at the same object that the discovery rule of Section 5.2 names at the Trust Anchor's own publication point; * a single blank line; and * the base64 encoding ([RFC4648]) of the DER-encoded Trust Anchor post-quantum 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 Li & Chung Expires 21 January 2027 [Page 26] Internet-Draft pqRPKI July 2026 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. 9. Algorithm Profile and Agility 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. 10. Issuer Behavior A CA that supports pqRPKI MUST, for each publication point: 1. Maintain the Manifest fileList in a stable slot order within a signing epoch (Section 4.3): the CRL and the Manifest are handled as metadata (Section 4.5), and the CA's PQLO is never listed (Section 5.2). No lexicographic ordering is required; the wire order is authenticated by manifestHash. Li & Chung Expires 21 January 2027 [Page 27] Internet-Draft pqRPKI July 2026 2. Preserve object leaf indices within a signing epoch by holding slots stable: append new objects, and replace a removed or hidden object in its existing slot with a uniquely named placeholder (Section 7.2) rather than dropping it, until a planned compaction or key-rollover boundary. Placeholder publication is subject to the legacy-compatibility constraint of Section 7.5. 3. Compute the CA Ladder and ladderRoot per Section 4 using the algorithm named in hashAlgorithm, and populate rungDescriptors to match. 4. If the CA has pqRPKI-aware children, compute the aggregate and aggregateRoot per Section 6 and populate children: for each hosted child, the current childTBSHash; for each delegated child, its childPQPublicKey. 5. Populate the remaining TBS fields, ensuring caKeyIdentifier, manifestHash, manifestNumber, thisUpdate, and nextUpdate equal the corresponding CA-certificate and Manifest values, and DER- encode the TBS. 6. If the CA holds its own post-quantum key (a Trust Anchor or any delegated CA), set 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). 7. Wrap the 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. 8. Publish the changed objects, the CRL, the Manifest, and the PQLO in one repository update, so that RPs observe them atomically (for example, in a single [RFC8181] exchange and hence a single RRDP delta). A PQLO MUST be reissued whenever the Manifest it commits to is reissued, MUST be published in the same repository update as that Manifest, and its 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). Li & Chung Expires 21 January 2027 [Page 28] Internet-Draft pqRPKI July 2026 11. Relying Party Behavior 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: 1. Establish that C is pqRPKI-aware: C is a Trust Anchor for which the RP has a pqTAL, or C has a ChildBinding in the aggregate of a parent whose own TBS this RP has already authenticated. Derive the URI of C's PQLO from C's 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. 2. Check that the PQLO's 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. 3. Derive object leaves from C's Manifest in wire order (Section 4.3, Section 4.2), including placeholder entries and separating the CRL and Manifest metadata leaves; use the wire- order position as the leaf index and do not re-sort. The order needs no lexicographic check: it is authenticated by the manifestHash verified in the previous step. Li & Chung Expires 21 January 2027 [Page 29] Internet-Draft pqRPKI July 2026 4. Reconstruct the CA Ladder bottom-up (Section 4), reusing internal nodes across objects, and verify that the reconstructed 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. 5. Authenticate C's TBS against the already-authenticated parent: * If C's PQLO has a 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. * If C's PQLO has no 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. Li & Chung Expires 21 January 2027 [Page 30] Internet-Draft pqRPKI July 2026 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). 12. Migration Modes 12.1. Dual-Stack Mode 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. 12.2. Post-Quantum-Required Mode 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 Li & Chung Expires 21 January 2027 [Page 31] Internet-Draft pqRPKI July 2026 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"). 12.3. Router Interface pqRPKI does not change the RP-to-router protocol or the payload format. Routers consume RP output as they do today. 13. Operational Considerations 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"). Li & Chung Expires 21 January 2027 [Page 32] Internet-Draft pqRPKI July 2026 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. 14. Security Considerations 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 Li & Chung Expires 21 January 2027 [Page 33] Internet-Draft pqRPKI July 2026 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. Li & Chung Expires 21 January 2027 [Page 34] Internet-Draft pqRPKI July 2026 *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). Li & Chung Expires 21 January 2027 [Page 35] Internet-Draft pqRPKI July 2026 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 Li & Chung Expires 21 January 2027 [Page 36] Internet-Draft pqRPKI July 2026 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. 15. IANA Considerations 15.1. SMI Security for S/MIME CMS Content Type 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. 15.2. SMI Security for S/MIME Module Identifier 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. 15.3. RPKI Repository Name Scheme 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. Li & Chung Expires 21 January 2027 [Page 37] Internet-Draft pqRPKI July 2026 15.4. Media Type IANA is requested to register the media type application/rpki-pqlo for the PQLO, following the RPKI signed-object media-type template. 15.5. Post-Quantum Algorithm Identifiers 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"). 16. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, . [RFC6268] Schaad, J. and S. Turner, "Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)", RFC 6268, DOI 10.17487/RFC6268, July 2011, . [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for Resource Certificate Repository Structure", RFC 6481, DOI 10.17487/RFC6481, February 2012, . Li & Chung Expires 21 January 2027 [Page 38] Internet-Draft pqRPKI July 2026 [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, February 2012, . [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, . [RFC6916] Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April 2013, . [RFC7935] Huston, G. and G. Michaelson, "The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8630] Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, August 2019, . [RFC9286] Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, June 2022, . [RFC9981] Harrison, T., Michaelson, G., and J. Snijders, "Resource Public Key Infrastructure (RPKI) Manifest Number Handling", RFC 9981, DOI 10.17487/RFC9981, May 2026, . 17. Informative References [Falcon] Fouque, P-A., Hoffstein, J., Kirchner, P., Lyubashevsky, V., Pornin, T., Prest, T., Ricosset, T., Seiler, G., Whyte, W., and Z. Zhang, "Falcon: Fast-Fourier Lattice- based Compact Signatures over NTRU - Specification v1.2", October 2020, . Li & Chung Expires 21 January 2027 [Page 39] Internet-Draft pqRPKI July 2026 [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", NIST FIPS 204, August 2024, . [I-D.harvey-cfrg-mtl-mode] Harvey, J., Kaliski, B., Fregly, A., Sheth, S., and D. McVicker, "Merkle Tree Ladder (MTL) Mode Signatures", Work in Progress, Internet-Draft, draft-harvey-cfrg-mtl-mode- 09, 24 March 2026, . [I-D.ietf-sidrops-publication-server-bcp] Bruijnzeels, T., de Kock, T., Hill, F., Harrison, T., and J. Snijders, "Best Practices for Operating Resource Public Key Infrastructure (RPKI) Publication Services", Work in Progress, Internet-Draft, draft-ietf-sidrops-publication- server-bcp-09, 29 May 2026, . [I-D.ietf-sidrops-rpki-erik-protocol] Snijders, J., Bruijnzeels, T., Harrison, T., and W. Ohgai, "The Erik Synchronization Protocol for use with the Resource Public Key Infrastructure (RPKI)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-erik- protocol-05, 6 July 2026, . [I-D.yoshikawa-sidrops-pqc-rpki] Yoshikawa, T., "Post-Quantum Signature Algorithm Profile and Migration Considerations for the Resource Public Key Infrastructure (RPKI)", Work in Progress, Internet-Draft, draft-yoshikawa-sidrops-pqc-rpki-01, 4 July 2026, . [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, . [RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A Protocol for Provisioning Resource Certificates", RFC 6492, DOI 10.17487/RFC6492, February 2012, . Li & Chung Expires 21 January 2027 [Page 40] Internet-Draft pqRPKI July 2026 [RFC8181] Weiler, S., Sonalker, A., and R. Austein, "A Publication Protocol for the Resource Public Key Infrastructure (RPKI)", RFC 8181, DOI 10.17487/RFC8181, July 2017, . [RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein, "The RPKI Repository Delta Protocol (RRDP)", RFC 8182, DOI 10.17487/RFC8182, July 2017, . [RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile for RPKI Signed Checklists (RSCs)", RFC 9323, DOI 10.17487/RFC9323, November 2022, . [RFC9582] Snijders, J., Maddison, B., Lepinski, M., Kong, D., and S. Kent, "A Profile for Route Origin Authorizations (ROAs)", RFC 9582, DOI 10.17487/RFC9582, May 2024, . Implementation Status 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. Acknowledgements The authors thank the members of the SIDROPS Working Group for discussions of this work at IETF 123, IETF 124, and IETF 125. Li & Chung Expires 21 January 2027 [Page 41] Internet-Draft pqRPKI July 2026 Open Issues for Working Group Review * File-name extension: RFC 9286 Section 4.2.2 currently requires a three-letter, registered extension. Confirm the concrete extension to register (the document uses ".pq" editorially) and whether to instead relax the grammar. * PQLO discovery: this version derives the PQLO URI from the 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. * Trust-anchor key distribution: confirm the companion pqTAL (Section 8) versus an update to RFC 8630 permitting a second key versus a separate SIDROPS document. * Delegated key enrollment: how a delegated child conveys its post- quantum public key to its parent, and how that conveyance is authenticated -- for example, through an extension to [RFC6492] (Section 6.2). * Algorithm identifiers: coordinate FN-DSA-512 and ML-DSA-65 OIDs and AlgorithmIdentifier parameter conventions with the RPKI algorithm profile and PKIX/LAMPS ([RFC7935], [RFC6916]). * Signed-root object structure: confirm carrying the ladder root, rung descriptors, and aggregate in one signed object versus splitting a minimal signed root from a descriptor object. * Leaf-index model: this version derives each leaf index from the Manifest wire-order position (authenticated by 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. * Post-quantum-only object profile: the encoding of RPKI objects, Manifests, and the PQLO itself once RSA material is no longer published (Section 12.2). * Hash strength: confirm whether SHA-256 leaf commitments (inherited from the Manifest) suffice for the desired long-term post-quantum margin, or whether a future Manifest hash profile is needed. Li & Chung Expires 21 January 2027 [Page 42] Internet-Draft pqRPKI July 2026 * Aggregate scaling: confirm the flat child-binding ladder is adequate at registries with tens of thousands of children, or whether an RP needs per-child authentication paths rather than the full child list (see also the size discussion in Section 13). * Parent PQLO freshness: a parent's aggregate changes whenever a hosted child's TBS changes, even though the parent's own Manifest has not. This version requires a PQLO to be reissued with the Manifest it commits to (Section 10), which leaves two parent PQLO revisions able to carry identical 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. * Trust Anchor post-quantum key rollover: a pqTAL key is preconfigured out of band and cannot roll in band, so pqRPKI is least agile exactly where a compromise is most costly. A rollover and algorithm-transition procedure, analogous to RFC 6489 for RPKI keys, is needed. * Mandatory-to-implement algorithm: FN-DSA-512 is specified here for its compactness, but FIPS 206 is not yet published and Falcon-512 is NIST security category 1. Confirm whether the MTI should instead be ML-DSA-65 (FIPS 204, published) with FN-DSA-512 permitted, and whether Trust Anchor and delegated-intermediate keys need a higher minimum security category or a hash-based algorithm. * Placeholder entries reduce the completeness property that Manifests provide: a CA may list entries no RP will ever fetch or check, and legacy and upgraded RPs may compute different results for the same repository state (Section 7.5). Confirm whether the H (hidden) family belongs in this version, and whether a D placeholder should be normatively required to retain the exact commitment previously published at that index so that a warm-cache RP can verify it. * Identity binding: the TBS binds the CA it speaks for only through a 20-octet SHA-1 SubjectKeyIdentifier, while ChildBindings already carry a SHA-256 childCertificateHash. Confirm whether to add a self caCertificateHash and to pair the pqTAL cryptographically with the TAL. Authors' Addresses Li & Chung Expires 21 January 2027 [Page 43] Internet-Draft pqRPKI July 2026 Weitong Li Virginia Tech Email: weitongli@vt.edu Taejoong Chung Virginia Tech Email: tijay@vt.edu Li & Chung Expires 21 January 2027 [Page 44]