Kyoto University

JP yoshikawa.tomoki.67i@st.kyoto-u.ac.jp

cyberstorm.mu

MU logan@cyberstorm.mu

Operations and Management SIDROPS RPKI PQC ML-DSA SLH-DSA SIDROPS This document reports experiments with post-quantum signature algorithms and analyzes migration approaches for the Resource Public Key Infrastructure (RPKI). The experiments compare classical, post-quantum, and composite signature candidates; generate and validate RPKI-profiled certificate, CRL, manifest, and ROA test objects; evaluate Parallel Publication and Mixed Tree migration as distinct migration structures; and evaluate the effect of larger objects on rsync, RRDP, and Erik Synchronization. The results identify implementation, interoperability, repository-distribution, and operational questions that need to be resolved before a production algorithm profile or transition procedure can be specified. This document is informational. It does not update RFC 7935 or RFC 6916, define a new RPKI algorithm profile, or authorize the use of the evaluated algorithms or Mixed Tree migration in the production RPKI.

Introduction The RPKI relies on digital signatures in resource certificates, CRLs, certification requests, and CMS signed objects such as manifests and Route Origin Authorizations (ROAs). The deployed RPKI algorithm profile is based on RSA with SHA-256. A Cryptographically Relevant Quantum Computer (CRQC) capable of executing the required quantum algorithms would undermine the unforgeability of the RSA signatures used by the deployed RPKI profile. Preparing for that risk requires measurements and interoperable implementations before a production transition procedure can be selected. This document records that preparatory work. The cryptographic-object and migration experiments preserve existing RPKI payload formats and router-facing validated payload interfaces. The repository-distribution experiment separately compares rsync, RRDP, and Erik Synchronization under the larger object sizes. Certification Authority (CA) and Relying Party (RP) implementations require support for the additional signature algorithms. The Mixed Tree experiment additionally evaluates a certificate-path construction that is not permitted by the migration procedure in RFC 6916. Routers that consume Validated ROA Payloads (VRPs) through the RPKI-Router Protocol (RTR) or local files do not process the evaluated signatures directly. The descriptions of algorithms, encodings, validation behavior, and migration steps in this document are experimental assumptions and observations. They are not interoperability requirements for production RPKI implementations.

Terminology This document uses the terminology of the RPKI architecture , the resource certificate profile , the RPKI signed object template , the RPKI algorithm agility procedure , and the RPKI algorithm profile . Current Suite: The algorithm suite specified by the currently applicable production RPKI algorithm profile. At the time of writing, this is RSA-2048/SHA-256 as profiled by RFC 7935. Next Suite: A candidate algorithm suite that is implemented and tested before it becomes the Current Suite. Mixed Tree: An experimental RPKI certification hierarchy in which a parent CA using the Current Suite signs a child CA certificate whose subject public key uses the Next Suite, allowing the child subtree to use the Next Suite while its ancestors remain on the Current Suite. Parallel Publication: A migration approach in which products that correspond as defined in are published under both the Current Suite and the Next Suite during a transition period. Composite Signature: A signature construction that combines multiple component algorithms into one algorithm identifier and signature value. In the LAMPS construction evaluated by this document, verification succeeds only when every component signature validates.

Scope The algorithm-profile analysis in this document applies to RPKI resource certificates, CRLs, certification requests, BGPsec Router Certificates , and the CMS signed objects that reuse the RPKI signed object template , including manifests , ROAs , Signed Checklists (RSC) , ASPA objects , and Trust Anchor Key (TAK) objects . The generated signed objects in this revision cover manifests and ROAs; additional object types are listed in the Implementation Status section. The CMS signed objects are treated as a single signed-object algorithm profile, as described in the following section. This document covers the RPKI signatures on BGPsec Router Certificates, but does not define or change the BGPsec UPDATE signature algorithm specified by . For a BGPsec Router Certificate, the experiment applies only to the certificate signature made by the issuing RPKI CA. The subject public key algorithm remains governed by the BGPsec UPDATE algorithm profile and is not required to match the RPKI certificate-signature suite. This document does not specify changes to RTR, TAL formats, RRDP , rsync, the RPKI Certificate Policy, or the BPKI used to authenticate provisioning and publication relationships established through . BPKI algorithm migration is a related operational problem, but is not evaluated by this document and need not use the same algorithm or transition schedule as RPKI repository objects. This document does not modify RRDP or rsync; it separately evaluates their transport costs, together with Erik Synchronization, under the larger object sizes used by the experiment.

Signed Object Coverage Manifests , ROAs , Signed Checklists , ASPA objects , TAK objects , and any future object types built on the RFC 6488 template share one CMS structure, one EE certificate model, one certification infrastructure, and one repository. The evaluation model therefore treats them as one signed-object algorithm profile. Migrating, for example, ROAs to a PQC suite while leaving ASPA objects on RSA would introduce per-object-type algorithm diversity, leaving part of the RPKI signed-object set dependent on the Current Suite. Changing only the CMS signature algorithm does not change an object's eContentType or object-specific payload syntax. Some objects, notably TAK objects, may nevertheless carry public keys whose algorithms change as part of a wider trust-anchor migration and therefore require separate object-specific interoperability testing. A future standards-track profile that selects a new mandatory RPKI algorithm suite would update . An object-specific RFC needs an update only if that object's payload or validation semantics also change; this document makes no such change. BGPsec UPDATE signatures are not RFC 6488 signed objects and are outside this experiment. BGPsec Router Certificates and their covering CRLs and manifests are repository products and remain part of the evaluation scope.

Relationship to RFC 6916 RFC 6916 specifies a top-down algorithm transition using parallel certification hierarchies. It also states that an RPKI CA does not sign a CA certificate whose subject key corresponds to an algorithm suite different from the suite used to sign that certificate. The Mixed Tree experiment described in this document deliberately evaluates the X.509 construction excluded by RFC 6916. Objects produced by this experiment are therefore confined to test TALs and test repositories. Production use of this construction would require separate Standards Track work updating or replacing the applicable algorithm profile and migration procedure.

Evaluation Goals The experiments use the following evaluation goals.

• Preserve the existing RPKI object and validation model when evaluating signature-algorithm changes.
• Reuse existing LAMPS PKIX and CMS encodings for PQC algorithms.
• Avoid new RPKI object formats unless measurements show that simple signature substitution is infeasible.
• Keep routers as consumers of validated payloads, not PQC validators, while acknowledging that RP validation and repository processing change.
• Apply one signature algorithm suite uniformly to all RFC 6488 signed objects rather than per-object-type algorithm choices.
• Evaluate the conditional EUF-CMA guarantee provided by a composite construction when one component remains secure, subject to the assumptions of the referenced LAMPS construction.
• Examine the operational effects of a prolonged period in which the Current Suite and Next Suite coexist.
• Identify operational measurements needed to detect differences in validated outputs during an algorithm transition.
• Keep measurement and interoperability evidence reproducible outside the protocol specification.

Experimental Migration Approaches This section describes the two migration approaches evaluated in this document. The choice of signature suite is independent of this comparison.

Parallel Publication RFC 6916 specifies a top-down transition in which a parent CA adopts support for the Next Suite before its children. During phases 2 and 3, corresponding Current Suite and Next Suite product sets are maintained in parallel. RFC 6916 deliberately avoids mixed-suite CA certificates: a CA certificate signed using one suite does not carry a subject key associated with another suite. The Parallel Publication experiment publishes corresponding Current Suite and Next Suite products separately. It does not define new payload encodings for manifests, ROAs, or CRLs. As described in Section 6 of , RPs can retrieve product sets under both algorithm suites and compare their outputs for testing. This experiment performs that comparison using the resulting VRP sets and CCR . The experimental harness needs a mapping between corresponding products for measurement and debugging. Such a mapping can be derived from the publication point structure, object names, CA hierarchy, or an implementation-specific record. It is not proposed as a new on-wire RPKI object.

Mixed Tree A parent using the Current Suite signs a child CA certificate whose subject public key belongs to the Next Suite. The child then issues its certificates, CRLs, and CMS signed objects using the Next Suite without first requiring the parent to migrate its own CA key and product set. Production issuance would still require the parent to process the child's Next Suite certificate request and proof of possession. This experiment constructs the child CA certificate directly; it has not implemented that provisioning exchange. The Mixed Tree migration approach is independent of the selected signature suite. The evaluated repository instantiates the Next Suite with the Composite ML-DSA configuration evaluated in this revision. This construction is not permitted by the RFC 6916 transition procedure and is evaluated only as an experimental alternative under test TALs. Unlike the RFC 6916 procedure, a switched subtree does not maintain corresponding Current Suite and Next Suite products. This avoids duplicate repository content and the publication, configuration, and rollover work needed to keep two product sets aligned. It also permits subtrees to move independently after the necessary parent and RP support is available, rather than waiting for every ancestor to migrate its own CA key and product set. The trade-off is compatibility. Once a subtree switches, an RP that does not support the Next Suite cannot validate it through the certification path. Mixed Tree deployment therefore replaces the parallel legacy hierarchy with a requirement for sufficient RP support before each subtree is migrated. The complete certification path remains dependent on Current Suite certificate signatures above the migration boundary.

Migration model	Migration ordering	Legacy RP compatibility	Parallel products	Principal limitation
RFC 6916 Parallel Publication	Top-down	Current Suite hierarchy remains available	Required during transition	Repository and operational duplication
Mixed Tree	Per subtree after required support is available	Unsupported RPs lose the switched subtree	Not required within the switched subtree	The path still depends on Current Suite ancestors

The experiment uses test repositories and test TALs. It does not define or authorize a production transition procedure.

Evaluated Algorithm Suites

Current Suite The Current Suite baseline used by this experiment is RSA PKCS #1 v1.5 with SHA-256 as specified by RFC 7935. This document does not set a production transition timetable.

Composite Configuration Evaluated in This Revision The composite signature construction used by this experiment is defined in revision 19 of . The evaluated configuration is id-MLDSA65-ECDSA-P256-SHA512 (OID 1.3.6.1.5.5.7.6.45), whose identifier and component-algorithm combination are specified by that document. It combines ML-DSA-65 with ECDSA P-256 and requires both component signatures to validate. The corresponding CMS use is specified by . The choice of this composite configuration is an experimental input, not a recommendation for production deployment. The object experiment applies to composite public keys and certificate signatures, and to composite CMS SignedData. The public reference implementation has generated complete composite X.509 certificates, CRLs, ROAs, and manifests and has validated a Mixed Tree with an RSA parent and a Composite child using experimental rpki-client and Routinator extensions. The two RP processing paths share one OpenSSL and Composite provider backend, so this is not independent cryptographic interoperability evidence. Experiments with the composite suite are confined to isolated repositories under test TALs. Experimental objects, production repositories, production keys, and production TALs are deliberately kept separate.

Additional Candidate Suites ML-DSA-44 is an additional experimental configuration. It produces smaller public keys and signatures and may sign and verify faster, which matters in a system where RPs repeatedly synchronize repository state and validate large numbers of objects. This revision uses ML-DSA-65 in the composite configuration as an explicit experimental choice, not because the RPKI requires NIST security Category 3. The Rationale for the Experimental Configurations section discusses this choice and its counterarguments. ML-DSA-87 is included as a higher-security comparison candidate. It is more conservative than ML-DSA-65 but carries correspondingly larger size and performance costs. SLH-DSA-SHAKE-128s and SLH-DSA-SHAKE-192s are included for cryptographic-diversity comparison. Their signature algorithm, PKIX, and CMS specifications are defined by , , and . They are not proposed as the initial suite in this revision because their signature sizes are substantially larger than those of ML-DSA in the evaluated configurations. FN-DSA (Falcon), MAYO, and SNOVA are additional candidates for future evaluation. They are outside the present evaluation until stable PKIX and CMS profiles are available and referenced by a future revision or separate document. FN-DSA in particular is discussed further in the Rationale for the Experimental Configurations section, because its compact signatures make it an attractive candidate for the RPKI's bulk validation model. Other Composite ML-DSA combinations specified by LAMPS remain candidates for comparison. Changing the component pair would change object sizes and cryptographic costs, but would not determine whether a deployment uses Parallel Publication or Mixed Tree migration. RP support for a selected suite remains a deployment prerequisite.

Classical Reference Points To relativize the cost of PQC candidates, this document uses two compact classical algorithms as non-normative reference points: ECDSA P-256 with SHA-256 , which is already used for BGPsec UPDATE signatures , and Ed25519 . Neither is a CRQC-resistant algorithm, and neither is proposed here as an RPKI suite. They provide compact classical reference points for signature and key sizes in the classical setting: the deployed RSA-2048 profile is itself several times larger than these curves, and PQC candidates should be compared against both baselines rather than against RSA alone.

Size Model Inputs The table below records the values supplied to the first-order size model. The representations are deliberately mixed: some rows use raw public keys or fixed-width signatures, while others use representative DER values or a maximum encoded signature size. They are therefore model inputs, not a uniform comparison of SubjectPublicKeyInfo or signature encodings.

Algorithm	Cat.	Key representation used by model (B)	Signature representation used by model (B)
RSA-2048/SHA-256	n/a	270	256
P-256/SHA-256	n/a	65	~72
Ed25519	n/a	32	64
ML-DSA-44	2	1312	2420
ML-DSA-65	3	1952	3309
ML-DSA-87	5	2592	4627
FN-DSA-512 (Falcon)	1	897	<=666
SLH-DSA-SHAKE-128s	1	32	7856
SLH-DSA-SHAKE-192s	3	48	16224

"Cat." is the NIST security category; "n/a" marks classical reference algorithms. The RSA-2048 key value is a representative DER RSA public-key value used by the model. The P-256 value is an uncompressed point, and the Ed25519, ML-DSA, FN-DSA, and SLH-DSA values are raw public keys. The ECDSA value is a representative DER signature size, while FN-DSA records a maximum. These choices are documented so that later models can replace them with consistently measured RPKI object encodings. Beyond static sizes, the evaluation considers the following dimensions: certificate and CRL size under the RPKI profile; CMS signed object size; signing and verification cost under the RP workload; impact on repository size and on distribution via RRDP, rsync, and Erik; CA key rollover and publication cycle impact; HSM support; and standardization and implementation maturity. The dimensions backed by measurements in this revision are identified in Appendix A. Two qualitative observations from the preliminary evidence inform the rationale in the next section. First, RP workload is verification dominated: an RP verifies repository objects but signs nothing as part of validation, and the deployed RSA profile is exceptionally cheap at verification, so increases in verification cost are particularly relevant to RP operation. Second, first-order size models place ML-DSA-65 near a fourfold repository size increase over the RSA baseline, ML-DSA-44 near threefold, and FN-DSA-512 well below twofold. Measurements supporting these observations, together with their conditions, caveats, and the list of dimensions not yet backed by confirmed measurements, are collected in Appendix A and are maintained in reproducible form by the experimental harness . Measured values are implementation and environment dependent and are not protocol requirements.

Rationale for the Experimental Configurations This experiment evaluates a composite suite because a global RPKI migration may benefit from not depending exclusively on a newly deployed PQC algorithm. The LAMPS construction accepts a composite signature only when both component signatures validate. Under the assumptions stated by that construction, its EUF-CMA guarantee is retained when at least one component remains EUF-CMA secure and the prehash remains collision resistant. This guarantee has a limit. A CRQC defeats the ECDSA component, so security against a quantum adversary still depends on ML-DSA-65 remaining secure. The composite suite also does not protect against failures shared by both components or by the combiner, encoding, key management, or validation implementation. It does not in general preserve strong unforgeability when only one component has that property. An implementation defect in one component can be tolerated only when the other component, the combiner, encodings, key handling, and the verification of all component signatures remain unaffected. ML-DSA-65 is used as the PQC component of the composite configuration evaluated in this revision because it has a final FIPS signature specification , corresponding PKIX and CMS algorithm identifier specifications, and implementations available in the software environment used by this experiment. This revision also chooses Category 3 as an experimental point for examining the cost of a larger security margin in a system in which another global algorithm migration could take multiple years. This is not an RPKI requirement. It is not used because it is the smallest or fastest possible signature algorithm; it is neither. The choice between ML-DSA-44 and ML-DSA-65 is genuinely open. The argument for ML-DSA-65 is conservatism: the RPKI is a single global system, algorithm migrations in it are slow and expensive, and a larger security margin reduces the probability of needing another migration. The argument for ML-DSA-44 is that a structural cryptanalytic break of module lattices would likely affect all ML-DSA parameter sets, so the extra category mainly protects against gradual erosion of concrete security estimates rather than against a qualitative break; under that view, the roughly 25-35% smaller keys and signatures of ML-DSA-44, or a composite configuration using ML-DSA-44, may be a better use of the size budget . This document uses ML-DSA-65 in the composite configuration measured in this revision, keeps ML-DSA-44 in the comparison, and records the parameter-set choice as a question for further work. ML-DSA-87 provides a higher-security comparison point, but its size and performance costs make it less attractive in the evaluated repository model. FN-DSA (Falcon) is an attractive candidate on size and performance grounds: its signatures are roughly one fifth the size of ML-DSA-65 signatures, and both published RPKI analysis and repository-scale redesign work identify Falcon as the compact lattice option. This document nevertheless treats FN-DSA as an additional configuration for future evaluation rather than one measured in the composite experiment, for the following reasons:

• This document does not profile FN-DSA because it does not reference a final FN-DSA standard together with stable PKIX and CMS profiles.

• Side-channel-resistant FN-DSA implementations and HSM support require separate implementation and deployment evaluation.

• Availability of FN-DSA in the platforms that RPKI CAs, RIRs, HSM vendors, and validator implementations actually use is a separate question from the algorithm's intrinsic merits. This experiment does not evaluate production RPKI CA or RP support for FN-DSA.

These are reasons to sequence the evaluation, not to dismiss the algorithm. FN-DSA remains in the comparison set as the compact signature candidate, and the conditions under which it should be examined further are recorded as questions for further work. Algorithm selection for the RPKI cannot be based on software benchmarks alone. HSM support for a candidate algorithm is also a deployment prerequisite for CAs that protect their signing keys in HSMs.

Experimental Object Encoding

Certificate and CRL Encoding The composite certificate and CRL experiment follows the encodings in . Under that assumption, a composite subject carries id-MLDSA65-ECDSA-P256-SHA512 in the SPKI AlgorithmIdentifier with absent parameters. A certificate or CRL signed by the composite issuer uses that identifier in its signatureAlgorithm field. A child CA certificate signed by a Current Suite issuer instead retains the issuer's Current Suite signatureAlgorithm while carrying the composite identifier in the subject SPKI. The same composite SPKI and signature encodings are assumed for resource certificate requests and their proof-of-possession signatures. Pure ML-DSA certificates and CRLs used for component measurements follow ; they provide component-level evidence and are not proposed as a production Next Suite. These request and proof-of-possession encodings are not exercised by the implementation in this revision. The generated RPKI test objects preserve the existing keyUsage constraints. CA certificates carry keyCertSign and cRLSign, while EE certificates for signed objects carry digitalSignature and are not used as CA certificates. The experiment does not change resource extension semantics, the certificate policy OID, certificate path validation, manifest processing, or CRL processing.

CMS Signed Object Encoding The composite CMS experiment combines with the RPKI signed object template in , as updated by . The assumed SignerInfo signatureAlgorithm is id-MLDSA65-ECDSA-P256-SHA512 with absent parameters. The SignedData digestAlgorithms set includes id-sha512, and the SignerInfo digestAlgorithm is id-sha512. The parameters are absent in both AlgorithmIdentifiers, and the message-digest signed attribute contains the SHA-512 digest of the eContent. The experiment retains the signedAttrs restrictions from the existing RPKI signed object profile: one content-type attribute, one message-digest attribute, and one signing-time attribute, with no binary-signing-time or other signed attributes. The eContentType, eContent, and object-specific validation rules remain unchanged. The implementation generated and validated complete Composite ROA and manifest SignedData using these encodings, together with the certificates and CRLs required for repository validation. Experimental rpki-client and Routinator extensions processed the resulting repository. Interoperability with a cryptographic implementation independent of the shared OpenSSL and Composite provider remains open work.

Manifest Processing During Migration A manifest covers the products of one CA instance at one publication point, as specified by and updated by . The manifest is signed with a one-time-use EE certificate issued by that CA. Its fileList contains the certificates issued and published by that CA, the CA's current CRL, and signed objects whose embedded EE certificates were issued by that CA. The relevant RP check is therefore issuer and publication-scope consistency, not equality between the manifest signing key and product keys. An RP validates the manifest EE certificate under the associated CA, verifies each listed certificate, CRL, or signed object under that same CA instance as required by its object profile, and checks the publication point, file name, and file hash according to . A shared publication point can contain products from multiple CA instances during key rollover, but each manifest covers only its associated CA instance. Mixed Tree migration and composite signatures do not change these checks. This document therefore introduces no additional requirement for the manifest EE key to equal a key used by a listed product, and it does not weaken the existing RP checks that bind every listed product to the manifest's CA scope.

Related Experimental Designs The cryptographic-object and Mixed Tree experiments preserve the existing X.509 resource-certificate and CMS signed-object model while changing signature algorithms and, in the Mixed Tree case, the certification path. The Null Scheme preserves the signed-object structure but replaces the one-time-use EE key pair and CMS signature with a public key derived from the message digest and an empty signature, reducing redundant cryptographic cost. pqRPKI instead introduces a Merkle Tree Ladder and restructures manifest, delegation, and bulk-verification processing. It is an alternative repository architecture rather than a direct algorithm substitution. Comparing these object-design alternatives requires separate measurements; the cryptographic-object experiments in this document cover only the structure-preserving approach.

Repository Distribution Considerations

Impact of Larger Objects Changing the signature suite affects more than cryptographic processing. Larger certificates, CRLs, manifests, and signed objects increase the bytes transferred during initial repository synchronization and in updates that contain those objects. The captured 1,000-ROA Composite repository occupied 9,797,552 object bytes, compared with 1,768,736 bytes for its RSA rollback state, a 5.54-fold increase. Transport scalability is therefore a deployment constraint that needs evaluation independently of algorithm correctness and RP validation time.

RRDP, rsync, and Erik Synchronization RRDP distributes snapshots and a journal of deltas. An RP obtains a complete snapshot when the notification file no longer offers a contiguous delta chain from the RP's serial, or when the session identifier changes. A polling RP can receive intermediate publication states that it does not ultimately use. An rsync synchronization first exchanges repository metadata and then transfers changed files; even an unchanged repository therefore has a cost that grows with the file list. Erik Synchronization is an RPKI- specific replication protocol using Merkle trees, content-addressable naming, and HTTP. An RP compares ErikIndex and ErikPartition objects and fetches selected objects by hash. Snapshot and segment prefetching can reduce the request cost of cache bootstrap and catch-up. This document does not specify Erik or require it for PQC deployment; it evaluates Erik alongside RRDP and rsync as a candidate response to repository expansion.

Transport Experiment Boundary Appendix A compares initial synchronization, an unchanged repository, one ROA replacement, and 10% ROA churn for RSA-2048, pure ML-DSA-65, and the evaluated Composite suite. It combines an actual local rsync run with calculated RRDP and Erik response-body sizes over the same deterministic corpus, calibrated to the measured object counts and repository sizes. The corpus preserves measured object counts and repository sizes but is not a cryptographically valid RPKI repository. The comparison is consequently evidence about byte growth, transferred bytes, and request counts, not a production-network throughput result.

Experimental Results

Results Summary OpenSSL 3.6.2 and the evaluated Composite provider generated complete certificate, CRL, manifest, and ROA sets for pure ML-DSA-65, Composite ML-DSA, and a Mixed Tree with an RSA parent and a Composite child. Experimental rpki-client and Routinator extensions validated each repository and produced the same two VRPs as the RSA baseline. An experimental Krill extension then created a Composite child below an RSA parent, published and replaced ROAs, and rolled the child back to RSA. Both experimental RPs derived the expected VRPs at each stage. The primary repeated cryptographic-operation benchmarks measure key generation, signing, and verification without X.509, CMS, repository transfer, or RP processing. Those rows use ten independent runs and give the median and sample standard deviation. Additional Composite ML-DSA operation measurements and their conditions are identified separately in Appendix A. Repository ratios are separate synthetic estimates derived from explicit object counts and measured key and signature sizes. Appendix A records the complete methods, results, and limitations. The two RP extensions use the same OpenSSL and Composite provider backend. The experiment therefore demonstrates two RP processing paths, but not independent cryptographic interoperability or production readiness.

Relying Party Evaluation The experiment extended rpki-client and Routinator to recognize the id-ml-dsa-65 and id-MLDSA65-ECDSA-P256-SHA512 identifiers and to delegate their cryptographic operations to OpenSSL providers. Each RP processed four complete repositories: the RSA baseline, pure ML-DSA-65, Composite ML-DSA, and a Mixed Tree with an RSA parent and a Composite child. For every repository, the test covered certificate-path and CRL validation, manifest and CMS validation, ROA processing, and VRP production. The Mixed Tree test additionally verified that the issuer signature algorithm and subject SPKI algorithm are processed independently. The RSA parent's public key verifies the signature on the child CA certificate, while the Next Suite public key carried in that certificate's SPKI is used to validate signatures issued by the child. When an experiment validates both Current Suite and Next Suite products, it separately compares their validated outputs. For ROAs, the comparison uses equality of the canonical VRP sets by prefix, maxLength, and origin AS. When both runs use the same CCR version and hash algorithm, equal ROAPayloadState hashes indicate equality of those canonical VRP sets under the collision-resistance assumption of the CCR digest . The experiment parsed actual rpki-client CCR DER for the RSA, pure ML-DSA-65, Composite, and Mixed Tree repositories and recomputed every embedded collection hash. All four ROAPayloadState hashes were equal, while ManifestState differed as expected. TrustAnchorState is compared separately and also differed. This result uses one RP implementation that produced CCR output. ROAPayloadState does not preserve per-VRP certificate-chain or publication provenance, so comparing the certificate chain and publication source associated with each VRP requires additional experiment records. Differences in validated outputs are recorded as an experimental result rather than silently merged. This document does not require routers to support PQC. Routers receive validated payloads through RTR or local export formats, and the semantic content of that output is intended to be unchanged by the algorithm migration.

Implementation Status This section records the status of the experiments at the time of posting this Internet-Draft, using the reporting pattern described in . It is intended to assist IETF discussion and is to be removed before publication as an RFC. pqc-rpki-lab is a research prototype used for the experiments described in this document. The lists below distinguish the implemented experimental coverage from remaining work. Implemented:

• Generation of complete pure ML-DSA-65 and Composite certificates, CRLs, manifests, and ROAs, including a Mixed Tree repository with an RSA parent and a Composite child.
• Experimental rpki-client and Routinator extensions that validate the RSA, pure ML-DSA-65, Composite, and Mixed Tree repositories and produce the expected VRPs.
• Experimental Krill issuance, publication, one-ROA replacement, and RSA rollback for a Composite child below an RSA parent.
• Object generation and validation, repository-size and scale experiments, RP-cache experiments, and rsync/RRDP/Erik transport accounting described in Appendix A.
• Fifteen negative cases for cryptographic and profile failures, seven cases for repository-operation failures, tests showing that removal of one child publication point leaves sibling VRPs unaffected, and CCR output comparisons.

Not yet implemented or incomplete:

• Composite certificate requests and proof of possession, BGPsec Router Certificates, and Composite ASPA, RSC, and TAK objects.
• Independent cryptographic interoperability and a second RP implementation capable of producing CCR output.
• Re-signing of a multi-CA corpus modeled on the public RPKI and production-network RRDP, rsync, and Erik measurements.
• HSM support, long-running RP resource use, and additional candidate suites.

The highest-priority gaps are independent cryptographic interoperability and validation over a multi-CA corpus modeled on the public RPKI that can be re-signed under each evaluated configuration.

Security Considerations This document addresses forgery of RPKI signatures in the presence of a CRQC. Existing considerations for CA compromise, repository compromise, operational misissuance, BGP policy mistakes, and route leaks are unchanged. A rollback to the Current Suite is a recovery mechanism only while that suite remains trustworthy and policy permits its use. After the Current Suite becomes forgeable, or after a deployment adopts a policy that permits only the Next Suite, such a rollback is a downgrade rather than recovery. Divergent algorithm policies and downgrade behavior are primary concerns during a long transition. Divergent suite-selection policies across the RP population can cause different RPs to derive different VRP sets from the same repository; this is a systemic risk of the transition period itself, and it persists for as long as classical and post-quantum algorithm suites coexist. Parallel Publication can produce different validation results between the Current Suite and Next Suite branches. For example, the RSA branch and the PQC branch might contain different ROA payloads, stale manifests, or different CRL state. The experiment detects and reports these cases rather than silently selecting one branch; see the Experimental Migration Approaches section. A Mixed Tree rooted in a Current Suite trust anchor is not quantum resistant as a complete certification path. Validation of the certification path depends on every certificate signature along it, including signatures made under the Current Suite. If an adversary can forge a Current Suite certificate signature above the migration boundary, the adversary can substitute a different Next Suite child key and construct a forged subtree. Mixed Tree migration is therefore suitable only while Current Suite certificate signatures remain trustworthy. It does not provide a recovery procedure after those signatures become forgeable, nor does it by itself establish a quantum-resistant trust anchor. Achieving end-to-end post-quantum security ultimately requires removing dependence on the Current Suite from the complete certification path. Trust-anchor migration and establishment of such a path are separate concerns from the Mixed Tree migration evaluated here. Larger public keys, signatures, certificates, CRLs, and CMS objects increase the network and processing resources required for repository retrieval and validation. A hostile or misbehaving publication point can impose disproportionate transfer and CPU cost on RPs, and PQC object sizes raise the ceiling of that cost. Resource limits and operational measurements of object size, object count, validation time, and memory use therefore belong in a production readiness evaluation. Production-network measurements of RRDP, rsync, and Erik Synchronization under projected repository sizes and churn rates are needed before large-scale deployment. HSM implementations of PQC algorithms are newer than their software counterparts and may lag in side-channel hardening, fault-attack resistance, and certification. A CA key that is protected against extraction but is used by an implementation that leaks sensitive information through side channels does not receive the intended level of protection. Side-channel resistance is algorithm- and implementation-dependent and requires separate evaluation for each candidate and platform. ML-DSA supports both deterministic and randomized signing. Signatures generated using either mode are interoperable. The experiment uses the signing mode selected by the implementation and does not compare the two modes. Randomized signing can make implementations easier to harden against fault and hardware side-channel attacks . Algorithm confusion is possible if AlgorithmIdentifier parameters, SignerInfo digestAlgorithm, CMS signed attributes, or certificate SubjectPublicKeyInfo encodings are inconsistently handled. The experimental validation criteria reject malformed AlgorithmIdentifier encodings and follow the parameter rules of the referenced LAMPS specifications. The LAMPS composite construction provides a conditional EUF-CMA guarantee only when every component is verified, at least one component remains EUF-CMA secure, and the prehash remains collision resistant. It does not generally preserve SUF-CMA from only one strongly unforgeable component. The experiment follows the component-key separation rules in ; reuse as standalone keys or in other composite combinations can enable stripping and cross-protocol attacks. A defect in one component is tolerated only if the other component and the combiner, parser, encoding, key management, and verification of all component signatures are unaffected. A shared implementation defect or compromise of both component keys is not mitigated by the composite construction. After a CRQC breaks ECDSA, the composite suite's unforgeability depends on ML-DSA-65.

IANA Considerations This document requests no IANA actions. It reuses algorithm identifiers defined by the referenced LAMPS specifications and defines no new RPKI object type, file extension, or content type.

Questions for Further Work The following questions require additional SIDROPS discussion and implementation evidence. The results reported here do not select a production suite or transition procedure.

Algorithm Configurations

• Whether ML-DSA-44, ML-DSA-65, or another candidate provides an appropriate balance of object size, signing and validation cost, security margin, and implementation availability for a future standards-track profile.
• Under what conditions FN-DSA should be promoted from a future evaluation candidate: completion of the FN-DSA standard, stable PKIX/CMS conventions, evidence of side-channel-resistant implementations, and HSM availability.

Migration Design

• Under what operational and compatibility conditions Parallel Publication or Mixed Tree migration provides an acceptable migration path.
• How RP readiness can be measured reliably before migrating a subtree in a production Mixed Tree deployment.
• How to define a transition timetable and readiness metrics, and whether that work should update or replace RFC 6916.
• How the EE subject public-key algorithm, the CA signature on the EE certificate, and the CMS signature algorithm should be related under a future Next Suite, including whether a null-signature construction should replace the current one-time-use EE model.
• How provisioning and publication software will roll the BPKI trust anchors and EE certificates used for existing relationships, including relationships established through , before those protocols depend on a PQC algorithm. The procedure needs overlap, rollback, and recovery behavior and can be prepared independently of the final RPKI object-signature algorithm choice.

Repository Distribution

• Whether RRDP and rsync remain operationally sufficient at projected PQC repository sizes, topology, polling intervals, and churn rates, or whether deployment requires a more selective mechanism such as Erik Synchronization.

Operational Readiness

• Which PQC signature algorithms RIR CA teams and their HSM vendors plan to support, on what firmware, API, certification, and deployment timelines.

Informative References This document describes an architecture for an infrastructure to support improved security of Internet routing. The foundation of this architecture is a Resource Public Key Infrastructure (RPKI) that represents the allocation hierarchy of IP address space and Autonomous System (AS) numbers; and a distributed repository system for storing and disseminating the data objects that comprise the RPKI, as well as other signed objects necessary for improved routing security. As an initial application of this architecture, the document describes how a legitimate holder of IP address space can explicitly and verifiably authorize one or more ASes to originate routes to that address space. Such verifiable authorizations could be used, for example, to more securely construct BGP route filters. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines a standard profile for X.509 certificates for the purpose of supporting validation of assertions of "right-of-use" of Internet Number Resources (INRs). The certificates issued under this profile are used to convey the issuer's authorization of the subject to be regarded as the current holder of a "right-of-use" of the INRs that are described in the certificate. This document contains the normative specification of Certificate and Certificate Revocation List (CRL) syntax in the Resource Public Key Infrastructure (RPKI). This document also specifies profiles for the format of certificate requests and specifies the Relying Party RPKI certificate path validation procedure. [STANDARDS-TRACK] This document defines a generic profile for signed objects used in the Resource Public Key Infrastructure (RPKI). These RPKI signed objects make use of Cryptographic Message Syntax (CMS) as a standard encapsulation format. [STANDARDS-TRACK] This document specifies the process that Certification Authorities (CAs) and Relying Parties (RPs) participating in the Resource Public Key Infrastructure (RPKI) will need to follow to transition to a new (and probably cryptographically stronger) algorithm set. The process is expected to be completed over a timescale of several years. Consequently, no emergency transition is specified. The transition procedure defined in this document supports only a top-down migration (parent migrates before children). This document specifies the algorithms, algorithms' parameters, asymmetric key formats, asymmetric key size, and signature format for the Resource Public Key Infrastructure (RPKI) subscribers that generate digital signatures on certificates, Certificate Revocation Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and certification requests as well as for the relying parties (RPs) that verify these digital signatures. In the Resource Public Key Infrastructure (RPKI), Certificate Authorities (CAs) publish certificates, including end-entity certificates, Certificate Revocation Lists (CRLs), and RPKI signed objects to repositories. Relying Parties retrieve the published information from those repositories. This document specifies a new RPKI Repository Delta Protocol (RRDP) for this purpose. RRDP was specifically designed for scaling. It relies on an Update Notification File which lists the current Snapshot and Delta Files that can be retrieved using HTTPS (HTTP over Transport Layer Security (TLS)), and it enables the use of Content Distribution Networks (CDNs) or other caching infrastructures for the retrieval of these files. This document defines a standard profile for X.509 certificates used to enable validation of Autonomous System (AS) paths in the Border Gateway Protocol (BGP), as part of an extension to that protocol known as BGPsec. BGP is the standard for inter-domain routing in the Internet; it is the "glue" that holds the Internet together. BGPsec is being developed as one component of a solution that addresses the requirement to provide security for BGP. The goal of BGPsec is to provide full AS path validation based on the use of strong cryptographic primitives. The end entity (EE) certificates specified by this profile are issued to routers within an AS. Each of these certificates is issued under a Resource Public Key Infrastructure (RPKI) Certification Authority (CA) certificate. These CA certificates and EE certificates both contain the AS Resource extension. An EE certificate of this type asserts that the router or routers holding the corresponding private key are authorized to emit secure route advertisements on behalf of the AS(es) specified in the certificate. This document also profiles the format of certification requests and specifies Relying Party (RP) certificate path validation procedures for these EE certificates. This document extends the RPKI; therefore, this document updates the RPKI Resource Certificates Profile (RFC 6487). This document defines a "manifest" for use in the Resource Public Key Infrastructure (RPKI). A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository. For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content. Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository. Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects. This document obsoletes RFC 6486. This document defines a standard profile for Route Origin Authorizations (ROAs). A ROA is a digitally signed object that provides a means of verifying that an IP address block holder has authorized an Autonomous System (AS) to originate routes to one or more prefixes within the address block. This document obsoletes RFC 6482. In the Resource Public Key Infrastructure (RPKI), Signed Objects are defined as Cryptographic Message Syntax (CMS) protected content types. A Signed Object contains a signing-time attribute, representing the purported time at which the object was signed by its issuer. RPKI repositories are accessible using the rsync and RPKI Repository Delta protocols, allowing Relying Parties (RPs) to synchronize a local copy of the RPKI repository used for validation with the remote repositories. This document describes how the CMS signing-time attribute can be used to avoid needless retransfers of data when switching between different synchronization protocols. This document updates RFC 6488 by mandating the presence of the CMS signing-time attribute and disallowing the use of the binary-signing-time attribute. A Trust Anchor Locator (TAL) is used by Relying Parties (RPs) in the Resource Public Key Infrastructure (RPKI) to locate and validate a Trust Anchor (TA) Certification Authority (CA) certificate used in RPKI validation. This document defines an RPKI signed object for a Trust Anchor Key (TAK). A TAK object can be used by a TA to signal to RPs the location(s) of the accompanying CA certificate for the current public key, as well as the successor public key and the location(s) of its CA certificate. This object helps to support planned key rollovers without impacting RPKI validation. Digital signatures are used within X.509 certificates and Certificate Revocation Lists (CRLs), and to sign messages. This document specifies the conventions for using FIPS 204, the Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in Internet X.509 certificates and CRLs. The conventions for the associated signatures, subject public keys, and private key are also described. The Module-Lattice-Based Digital Signature Algorithm (ML-DSA), as defined by NIST in FIPS 204, is a post-quantum digital signature scheme that aims to be secure against an adversary in possession of a Cryptographically Relevant Quantum Computer (CRQC). This document specifies the conventions for using the ML-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier syntax is provided. Entrust Limited Entrust Limited OpenCA Labs Bundesdruckerei GmbH Cisco Systems This document defines combinations of US NIST Module-Lattice-Based Digital Signature Algorithm (ML-DSA) in hybrid with traditional algorithms RSASSA-PKCS1-v1.5, RSASSA-PSS, ECDSA, Ed25519, and Ed448. These combinations are tailored to meet regulatory guidelines in certain regions. Composite ML-DSA is applicable in applications that use X.509 or PKIX data structures that accept ML-DSA, but where the operator wants extra protection against breaks or catastrophic bugs in ML-DSA, and where existential unforgeability (EUF-CMA) level security is acceptable. Entrust Limited Entrust Limited Bundesdruckerei GmbH CryptoNext Security Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) defines combinations of ML-DSA with RSA, ECDSA, and EdDSA. This document specifies the conventions for using Composite ML-DSA algorithms within the Cryptographic Message Syntax (CMS). National Institute of Standards and Technology This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document describes an out-of-band protocol for setting up RPKI provisioning and publication protocol relationships. This document specifies the algorithms, algorithm parameters, asymmetric key formats, asymmetric key sizes, and signature formats used in BGPsec (Border Gateway Protocol Security). This document updates RFC 7935 ("The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure") and obsoletes RFC 8208 ("BGPsec Algorithms, Key Formats, and Signature Formats") by adding Documentation and Experimentation Algorithm IDs, correcting the range of unassigned algorithms IDs to fill the complete range, and restructuring the document for better reading. This document also includes example BGPsec UPDATE messages as well as the private keys used to generate the messages and the certificates necessary to validate those signatures. This document defines a Cryptographic Message Syntax (CMS) protected content type for use with the Resource Public Key Infrastructure (RPKI) to carry a general-purpose listing of checksums (a 'checklist'). The objective is to allow for the creation of an attestation, termed an "RPKI Signed Checklist (RSC)", which contains one or more checksums of arbitrary digital objects (files) that are signed with a specific set of Internet Number Resources. When validated, an RSC confirms that the respective Internet resource holder produced the RSC. SLH-DSA is a stateless hash-based signature algorithm. This document specifies the conventions for using the SLH-DSA signature algorithm with the Cryptographic Message Syntax (CMS). In addition, the algorithm identifier and public key syntax are provided. Digital signatures are used within the X.509 Public Key Infrastructure, such as X.509 certificates and Certificate Revocation Lists (CRLs), as well as to sign messages. This document specifies the conventions for using the Stateless Hash-Based Digital Signature Algorithm (SLH-DSA) in the X.509 Public Key Infrastructure. The conventions for the associated signatures, subject public keys, and private keys are also specified. BSD Software Development RIPE NCC RIPE NCC OpenBSD This document specifies a Canonical Cache Representation (CCR) content type for use with the Resource Public Key Infrastructure (RPKI). CCR is a Distinguished Encoding Rules (DER) encoded data interchange format which can be used to represent various aspects of the state of a validated RPKI cache at a particular point in time. The CCR profile is a compact and versatile format, well-suited for a variety of applications, for example, audit trails, analytics pipelines, and validated payload dissemination. BSD Software Development Yandex JetLend Internet Initiative Japan Vigil Security, LLC Workonline This document defines a Cryptographic Message Syntax (CMS) protected content type for Autonomous System Provider Authorization (ASPA) objects for use with the Resource Public Key Infrastructure (RPKI). An ASPA is a digitally signed object through which the issuer (the holder of an Autonomous System identifier), can authorize one or more other Autonomous Systems (ASes) as its transit providers. When validated, an ASPA's eContent can be used for detection and mitigation of route leaks. BSD Software Development RIPE NCC APNIC JPNIC This document specifies the Null Scheme for use in Signed Objects in the Resource Public Key Infrastructure (RPKI). The Null Scheme is a niche signature scheme that can replace the redundant and costly use of actual digital signatures from so-called "one-time-use" key pairs in Signed Objects. The Null Scheme has as public key the digest of the message to be signed, and the signature is always empty. When a Null Scheme public key is the subject of a Signed Object's one-time- use End-Entity (EE) certificate, it establishes a secure binding between the issuer of the EE certificate and the message to be signed. This is cheaper in terms of size and verification time than using a real signature scheme, while providing the same security guarantees. Expired and archived National Institute of Standards and Technology National Institute of Standards and Technology Radboud University

Measurement Details This appendix records measurements referenced by the Size Model Inputs, Experimental Results, and Implementation Status sections. All values were produced by the experimental harness , which contains the corresponding scripts, raw outputs, and environment metadata. The harness remains the durable record.

Reproducibility Metadata The evidence snapshot cited by this revision is the GitHub release draft-yoshikawa-sidrops-pqc-rpki-02 of . The repository contains the scripts, raw outputs, and additional environment metadata used for the measurements in this appendix. The cryptographic-operation measurements were performed on an Apple M4 running macOS 26.5.2 with OpenSSL 3.6.2 and liboqs 0.15.0. The primary algorithm benchmark was compiled with optimization level -O2, while the Composite ML-DSA benchmark was compiled with -O3. The latter implements revision 19 of . The X.509, CMS, and RP experiments used OpenSSL 3.6.2 and the experimental Composite implementation recorded in the evidence snapshot. End-to-end validation was also exercised on a 12-vCPU x86-64 host using rpki-client 9.8. The RSA, pure ML-DSA-65, Composite, and Mixed Tree repositories all produced the expected VRPs.

Repeated Cryptographic Operation Timing This experiment compares the raw signing and verification cost of the evaluated algorithms independently of X.509, CMS, repository transfer, and RP processing. In particular, verification performance is relevant to RPs, which repeatedly validate large numbers of repository objects. The table reports the median and sample standard deviation across ten repetitions of 1,000 operations on a fixed 32-byte message. Values are wall-clock seconds per 1,000 operations.

Algorithm	Sign median	Sign stdev	Verify median	Verify stdev
RSA-2048/SHA-256	0.340326	0.002114	0.009792	0.000057
P-256/SHA-256	0.012660	0.000332	0.034535	0.005361
Ed25519	0.016657	0.006613	0.040442	0.018694
ML-DSA-44	0.249238	0.029970	0.047798	0.002460
ML-DSA-65	0.405729	0.017570	0.073411	0.014139
ML-DSA-87	0.477243	0.012468	0.115963	0.001536

The measurements show that RSA-2048 is substantially faster at verification than the other evaluated algorithms in this environment. ML-DSA verification cost increases with the parameter set, with ML-DSA-65 requiring about 7.5 times the RSA verification time and ML-DSA-87 about 11.8 times. Signing shows a different pattern: ML-DSA-44 is faster than RSA-2048, while ML-DSA-65 and ML-DSA-87 are somewhat slower. These measurements isolate cryptographic operations and therefore do not represent complete RP-validation performance. Their main implication for the RPKI is that algorithm selection should consider verification cost separately from signing cost, because RP workloads are verification dominated. The benchmark also covers 512-byte, 2-KiB, and 8-KiB messages and records key-generation timing, variance, and process peak RSS. Those raw results remain in the evidence snapshot rather than being duplicated here.

Composite ML-DSA Operation Measurements This experiment measures the additional cryptographic cost of combining ML-DSA with a classical signature algorithm in the Composite construction. It compares signing and verification time, public-key size, signature size, and the resulting synthetic repository-size ratio across the evaluated Composite configurations. The following single-run measurements execute 100,000 signing operations and 100,000 verification operations for each configuration. They include message-representative construction, ML-DSA context binding, both component signature operations, raw key and signature concatenation, and verification of all component signatures. The ML-DSA-87 configuration uses P-384 because revision 19 of does not define ML-DSA-87 with P-256.

Composite	Sign (s/100k)	Verify (s/100k)	PubKey (B)	Mean sig (B)	Repository ratio
ML-DSA-44 + P-256	26.0	8.3	1377	2491	3.16
ML-DSA-65 + P-256	45.6	11.9	2017	3380	4.09
ML-DSA-87 + P-384	59.4	32.8	2689	4730	5.40

The measurements show that both cryptographic cost and object size increase with the ML-DSA parameter set. For the evaluated ML-DSA-65 + P-256 configuration, the classical component adds relatively little to the repository-size ratio compared with ML-DSA-65 alone, while verification must still perform both component checks. These measurements isolate the Composite cryptographic operations. They exclude key generation, file I/O, X.509, CMS, RP processing, and HSM latency, and the repository ratios are synthetic model outputs rather than complete-repository measurements.

Measured Certificate and CRL Sizes This experiment measures the size impact of the evaluated signature algorithms when applied to RPKI-profiled certificates and CRLs. It provides measured object sizes for comparison with the repository-size models and transport experiments in the following sections. RFC 6487-profiled certificates, including RFC 3779 resource extensions, and CRLs were generated with OpenSSL 3.6.2. The RSA, P-256, Ed25519, ML-DSA, and SLH-DSA rows use the OpenSSL default provider. The FN-DSA-512 row uses the experimental provider described below.

Algorithm	CA cert (B)	EE cert (B)	CRL (B)
RSA-2048/SHA-256	1038	984	381
P-256/SHA-256	641	587	187
Ed25519	578	524	170
ML-DSA-44	4238	4184	2541
ML-DSA-65	5767	5713	3430
ML-DSA-87	7725	7671	4748
SLH-DSA-SHAKE-128s	8390	8336	7977
SLH-DSA-SHAKE-192s	16774	16720	16345
FN-DSA-512 (Falcon-512)	2048	1991	764

The P-256 and Ed25519 rows use the same RFC 6487 structure and resource extensions as the other rows, but are classical comparison algorithms rather than RFC 7935 suites. The FN-DSA-512 row uses the experimental Falcon-512 OID and encoding from oqs-provider 0.11.0-rc1 with liboqs 0.15.0; it is a measured experimental encoding, not a final FN-DSA PKIX profile. Falcon signatures are variable length, so its certificate and CRL sizes can vary between runs. The measurements show that certificate and CRL size varies substantially among the candidate algorithms. ML-DSA increases object size by several times relative to RSA-2048, while the evaluated SLH-DSA configurations produce substantially larger objects. FN-DSA-512 is comparatively compact in this experiment, although its measured encoding is not a final FN-DSA profile. These differences directly contribute to the repository-size and transport costs evaluated in the following sections.

Synthetic Repository Size Model This model estimates how the measured key and signature sizes translate into repository growth when applied across a representative set of RPKI objects. It is intended as a first-order comparison between candidate algorithms rather than as a prediction of the size of the global RPKI. The synthetic corpus contains 10 CA certificates, 100 EE certificates, 10 CRLs, 10 manifests, and 100 ROAs. Its base payload assumptions are 1500, 1500, 600, 1500, and 200 bytes, respectively. For certificates, the model adds both a public-key input and a signature input to the base payload. For CRLs, manifests, and ROAs, it adds the signature input. The resulting object sizes are multiplied by the corresponding object counts and summed. The repository ratio is then normalized to the RSA-2048 baseline. Transport encoding and cache overhead are not included.

Algorithm	Repository ratio
Ed25519	0.76
P-256	0.78
RSA-2048	1.00
FN-DSA-512	1.55
ML-DSA-44	3.08
ML-DSA-65	4.01
ML-DSA-65 + P-256 Composite	4.09
ML-DSA-87	5.28
SLH-DSA-SHAKE-128s	6.85
SLH-DSA-SHAKE-192s	13.38

As a consistency check, the same formula was applied to the standalone repository object counts: one CA certificate, two EE certificates, one CRL, one manifest, and one ROA. The measured medians are the four required products of the standalone repositories generated by the end-to-end experiment identified in the Reproducibility Metadata section. The error below is (predicted - measured) divided by measured.

Suite	Model prediction (B)	Measured median (B)	Model error
RSA-2048	9146	4843	+88.8%
ML-DSA-65 + P-256 Composite	33131	28855	+14.8%

For these counts, the model predicts a Composite-to-RSA ratio of 3.62, whereas the measured ratio is 5.96. The difference results primarily from the fixed base-payload assumptions, which overestimate the small RSA repository. The model shows that repository growth is strongly dependent on signature and public-key size. ML-DSA-44 and ML-DSA-65 produce approximately three- and four-fold increases over the RSA baseline in this corpus, while the evaluated Composite configuration is close to ML-DSA-65 because the additional P-256 component is small relative to the ML-DSA component. SLH-DSA produces substantially larger estimates, whereas FN-DSA remains comparatively compact. These ratios depend on the assumed object mix and base payload sizes and must not be treated as measured repository-wide growth factors. The measured repository experiments below provide more representative evidence for the configurations that were implemented.

Controlled Repository Scale Measurements This experiment examines how object generation and RP validation behave as the number of RPKI objects and child CAs increases. A public Routinator cache snapshot was used only as a reference for the scale of the deployed RPKI; the performance measurements themselves use controlled repositories. The reference snapshot, collected with Routinator 0.15.2 using RRDP, contained 550,210 objects across 54,960 publication points and produced 980,019 VRPs. The ARIN trust anchor was unavailable during collection, so these values do not represent the complete global RPKI. A controlled Krill experiment used one RSA parent and one Composite child. Complete repository generation was repeated 30 times for 1, 10, and 100 ROAs and 10 times for 1,000 ROAs. Each repository size was also validated 100 times with a fresh validator cache using the experimental rpki-client and Routinator implementations. Both RPs produced the expected VRPs in every run.

ROAs	Generation samples	Generation wall median (s)	Generation wall sample stdev (s)
1	30	6.990	0.244
10	30	7.675	0.348
100	30	19.360	0.519
1000	10	141.530	2.436

The captured 1,000-ROA Composite repository contained 1,008 files occupying 9,797,596 bytes. Its RRDP snapshot was 13,145,809 bytes uncompressed and 9,190,012 bytes with deterministic gzip. The same repository was used to compare validation with a fresh cache, an unchanged repository, and a one-ROA update, with 30 repetitions per RP and condition. The update changed the ROA, manifest, and CRL. rpki-client wall time medians were 0.86, 0.86, and 0.85 seconds, respectively; Routinator medians were 2.26, 1.99, and 2.30 seconds. The OS page cache was not controlled, so these results do not demonstrate a general incremental- validation speedup. A separate synthetic topology used one RSA parent and 100 Composite child CAs, each publishing one ROA. The repository contained 403 objects and produced 100 VRPs with both experimental RPs. Removing one child publication point reduced the result to 99 VRPs without affecting the remaining children. The results show that the prototype continues to produce the expected VRPs as the controlled repository grows, while repository generation cost increases substantially with the number of ROAs. The cache experiment does not show a consistent reduction in validation time after a small update, and the 100-child experiment confirms that failure of one child publication point does not invalidate sibling results. These experiments characterize controlled scaling behavior; they do not measure performance on the complete public RPKI or over production repository transport.

Repository Transport Measurements This experiment evaluates how larger RPKI objects affect repository synchronization under rsync, RRDP, and Erik Synchronization. It compares initial synchronization, an unchanged repository, a one-ROA update, and 10% ROA churn for RSA-2048, ML-DSA-65, and the evaluated Composite configuration. The experiment reused the measured 1,000-ROA repository size and object count. Each state contained 1,008 files: two certificates, three CRLs, three manifests, and 1,000 ROAs. The RSA and Composite totals were taken from captured repositories, while the ML-DSA-65 total was derived from measured certificate, CRL, manifest, and ROA sizes. For each transition, five local rsync runs started from the same cache state. RRDP values are calculated from notification, snapshot, and delta response bodies. Erik values use a simplified single-partition model with one ErikIndex, one ErikPartition, and the required objects fetched by hash. Protocol headers, TLS, connection setup, and Compression Dictionary Transport are not included.

Algorithm	State	Local rsync exchanged (B)	RRDP response bodies (B)	Erik response bodies (B)
RSA-2048	Initial	1,897,870	2,444,873	1,769,082
RSA-2048	Unchanged	60,562	184	113
RSA-2048	One ROA update	203,695	191,067	143,259
RSA-2048	10% ROA churn	370,906	413,520	303,738
ML-DSA-65	Initial	9,752,914	12,916,933	9,624,126
ML-DSA-65	Unchanged	60,562	184	113
ML-DSA-65	One ROA update	222,370	215,967	161,934
ML-DSA-65	10% ROA churn	1,163,068	1,469,604	1,095,900
Composite	Initial	9,926,678	13,147,301	9,797,898
Composite	Unchanged	60,562	184	113
Composite	One ROA update	169,476	145,451	109,048
Composite	10% ROA churn	1,133,142	1,429,580	1,065,982

The simplified Erik model required 1,010 requests for initial synchronization, one for an unchanged repository, five for a one-ROA update, and 104 for 10% churn. With snapshot prefetch, the modeled initial object transfer was consolidated into one bulk response of 1,768,736 bytes for RSA, 9,623,780 bytes for ML-DSA-65, and 9,797,552 bytes for Composite. The results show that larger signatures substantially increase transfer volume during initial synchronization and repository churn, while the cost of an unchanged repository remains small for RRDP and the modeled Erik case. Selective synchronization also avoids retransmitting most unchanged object data in the update scenarios. Repository distribution therefore becomes a more significant consideration as RPKI object sizes increase. These results do not establish the relative production performance of the three protocols. The rsync measurements were local, while the RRDP and Erik results are response-body models rather than measurements from production servers. Network latency, HTTP behavior, compression effects, and retrieval of obsolete intermediate states remain to be evaluated.

Open Measurement Tasks The following dimensions are not yet backed by confirmed measurements and are deliberately recorded as open tasks rather than numbers:

• CA key rollover, publication cycle, and full validation across the evaluated configurations over a multi-CA corpus modeled on the public RPKI that can be re-signed under each evaluated configuration. The controlled single-child and synthetic 100-child results do not reproduce public RPKI topology.
• Production RRDP, rsync, and Erik transfer, churn, polling-interval, and cache behavior. The generated bodies and local runs do not measure WAN behavior or obsolete intermediate-state transfer.
• Long-running validator memory and cache growth. The current results record process peak RSS for bounded executions only.
• HSM performance and support.

Changes from -01 This section is to be removed before publication as an RFC.

• Changed the intended status from Standards Track to Informational and reframed the document as an experiment report rather than an RPKI algorithm profile.
• Replaced interoperability requirements with experimental assumptions, observed behavior, and production-readiness questions.
• Added an explicit relationship to RFC 6916 and confined the Mixed Tree construction not permitted by RFC 6916 to test TALs and repositories.
• Distinguished RFC 6916 correspondence between products from equality of validated VRP results and separated CCR ROAPayloadState comparison from TrustAnchorState and comparison of certificate chains and publication sources.
• Clarified the conditional EUF-CMA guarantee and SUF-CMA limitation of the evaluated composite construction.
• Treated composite signatures, Mixed Tree migration, and Parallel Publication as independent design axes.
• Added repeated-run statistics, explicit synthetic-corpus inputs and formulas, tool versions, and compiler flags.
• Added Composite ML-DSA operation measurements, based on revision 19, for ML-DSA-44 with P-256, ML-DSA-65 with P-256, and ML-DSA-87 with P-384.
• Added experimental Krill Composite-child issuance, publication, one-ROA update, and rollback evidence validated by both experimental RPs.
• Added 15 cryptographic/profile and seven operational negative cases.
• Added a public-cache aggregate profile, repeated Krill measurements through 1,000 ROAs, a 1,000-ROA comparison under different cache conditions, and a 100-publication-point test showing that removal of one child publication point leaves sibling VRPs unaffected.
• Added actual rpki-client CCR DER parsing and verified equal ROAPayloadState hashes while keeping ManifestState, TrustAnchorState, and provenance separate.
• Added an rsync, RRDP, and Erik repository-transport comparison, with measured and modeled results explicitly distinguished.
• Kept a future production algorithm profile and transition procedure as separate standards work informed by these results.

Acknowledgements The authors thank Job Snijders, Dirk Doesburg, and Ties de Kock for their reviews and comments. The authors also thank the SIDROPS and LAMPS communities for the specifications and implementation work that make this experiment possible.