Post-Quantum Signature Experiments and Migration Considerations for the Resource Public Key Infrastructure (RPKI)
draft-yoshikawa-sidrops-pqc-rpki-02
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Tomoki Yoshikawa , Loganaden Velvindron | ||
| Last updated | 2026-08-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yoshikawa-sidrops-pqc-rpki-02
SIDROPS T. Yoshikawa
Internet-Draft Kyoto University
Intended status: Informational L. Velvindron
Expires: 21 February 2027 cyberstorm.mu
20 August 2026
Post-Quantum Signature Experiments and Migration Considerations for the
Resource Public Key Infrastructure (RPKI)
draft-yoshikawa-sidrops-pqc-rpki-02
Abstract
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.
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/.
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 February 2027.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 1]
Internet-Draft PQC for RPKI August 2026
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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Signed Object Coverage . . . . . . . . . . . . . . . . . . . 5
5. Relationship to RFC 6916 . . . . . . . . . . . . . . . . . . 6
6. Evaluation Goals . . . . . . . . . . . . . . . . . . . . . . 6
7. Experimental Migration Approaches . . . . . . . . . . . . . . 7
7.1. Parallel Publication . . . . . . . . . . . . . . . . . . 7
7.2. Mixed Tree . . . . . . . . . . . . . . . . . . . . . . . 7
8. Evaluated Algorithm Suites . . . . . . . . . . . . . . . . . 8
8.1. Current Suite . . . . . . . . . . . . . . . . . . . . . . 8
8.2. Composite Configuration Evaluated in This Revision . . . 9
8.3. Additional Candidate Suites . . . . . . . . . . . . . . . 9
8.4. Classical Reference Points . . . . . . . . . . . . . . . 10
8.5. Size Model Inputs . . . . . . . . . . . . . . . . . . . . 10
8.6. Rationale for the Experimental Configurations . . . . . . 12
9. Experimental Object Encoding . . . . . . . . . . . . . . . . 14
9.1. Certificate and CRL Encoding . . . . . . . . . . . . . . 14
9.2. CMS Signed Object Encoding . . . . . . . . . . . . . . . 14
9.3. Manifest Processing During Migration . . . . . . . . . . 15
10. Related Experimental Designs . . . . . . . . . . . . . . . . 15
11. Repository Distribution Considerations . . . . . . . . . . . 16
11.1. Impact of Larger Objects . . . . . . . . . . . . . . . . 16
11.2. RRDP, rsync, and Erik Synchronization . . . . . . . . . 16
11.3. Transport Experiment Boundary . . . . . . . . . . . . . 17
12. Experimental Results . . . . . . . . . . . . . . . . . . . . 17
12.1. Results Summary . . . . . . . . . . . . . . . . . . . . 17
12.2. Relying Party Evaluation . . . . . . . . . . . . . . . . 18
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 18
14. Security Considerations . . . . . . . . . . . . . . . . . . . 20
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
16. Questions for Further Work . . . . . . . . . . . . . . . . . 22
Yoshikawa & Velvindron Expires 21 February 2027 [Page 2]
Internet-Draft PQC for RPKI August 2026
16.1. Algorithm Configurations . . . . . . . . . . . . . . . . 22
16.2. Migration Design . . . . . . . . . . . . . . . . . . . . 22
16.3. Repository Distribution . . . . . . . . . . . . . . . . 23
16.4. Operational Readiness . . . . . . . . . . . . . . . . . 23
17. Informative References . . . . . . . . . . . . . . . . . . . 23
Appendix A. Measurement Details . . . . . . . . . . . . . . . . 27
A.1. Reproducibility Metadata . . . . . . . . . . . . . . . . 27
A.2. Repeated Cryptographic Operation Timing . . . . . . . . . 28
A.3. Composite ML-DSA Operation Measurements . . . . . . . . . 29
A.4. Measured Certificate and CRL Sizes . . . . . . . . . . . 30
A.5. Synthetic Repository Size Model . . . . . . . . . . . . . 31
A.6. Controlled Repository Scale Measurements . . . . . . . . 33
A.7. Repository Transport Measurements . . . . . . . . . . . . 35
A.8. Open Measurement Tasks . . . . . . . . . . . . . . . . . 37
Appendix B. Changes from -01 . . . . . . . . . . . . . . . . . . 37
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
1. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 3]
Internet-Draft PQC for RPKI August 2026
2. Terminology
This document uses the terminology of the RPKI architecture
[RFC6480], the resource certificate profile [RFC6487], the RPKI
signed object template [RFC6488], the RPKI algorithm agility
procedure [RFC6916], and the RPKI algorithm profile [RFC7935].
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 [RFC6916] 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.
3. Scope
The algorithm-profile analysis in this document applies to RPKI
resource certificates, CRLs, certification requests, BGPsec Router
Certificates [RFC8209], and the CMS signed objects that reuse the
RPKI signed object template [RFC6488], including manifests [RFC9286],
ROAs [RFC9582], Signed Checklists (RSC) [RFC9323], ASPA objects
[I-D.ietf-sidrops-aspa-profile], and Trust Anchor Key (TAK) objects
[RFC9691]. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 4]
Internet-Draft PQC for RPKI August 2026
This document covers the RPKI signatures on BGPsec Router
Certificates, but does not define or change the BGPsec UPDATE
signature algorithm specified by [RFC8608]. 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
[RFC8182], rsync, the RPKI Certificate Policy, or the BPKI used to
authenticate provisioning and publication relationships established
through [RFC8183]. 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.
4. Signed Object Coverage
Manifests [RFC9286], ROAs [RFC9582], Signed Checklists [RFC9323],
ASPA objects [I-D.ietf-sidrops-aspa-profile], TAK objects [RFC9691],
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 [RFC7935]. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 5]
Internet-Draft PQC for RPKI August 2026
5. 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.
6. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 6]
Internet-Draft PQC for RPKI August 2026
7. Experimental Migration Approaches
This section describes the two migration approaches evaluated in this
document. The choice of signature suite is independent of this
comparison.
7.1. 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 [RFC6916], 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 [I-D.ietf-sidrops-rpki-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.
7.2. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 7]
Internet-Draft PQC for RPKI August 2026
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 |Migration | Legacy RP | Parallel | Principal |
| model |ordering | compatibility | products | limitation |
+=============+==========+===============+============+=============+
| RFC 6916 |Top-down | Current Suite | Required | Repository |
| Parallel | | hierarchy | during | and |
| Publication | | remains | transition | operational |
| | | available | | duplication |
+-------------+----------+---------------+------------+-------------+
| Mixed Tree |Per | Unsupported | Not | The path |
| |subtree | RPs lose the | required | still |
| |after | switched | within the | depends on |
| |required | subtree | switched | Current |
| |support | | subtree | Suite |
| |is | | | ancestors |
| |available | | | |
+-------------+----------+---------------+------------+-------------+
Table 1
The experiment uses test repositories and test TALs. It does not
define or authorize a production transition procedure.
8. Evaluated Algorithm Suites
8.1. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 8]
Internet-Draft PQC for RPKI August 2026
8.2. Composite Configuration Evaluated in This Revision
The composite signature construction used by this experiment is
defined in revision 19 of [I-D.ietf-lamps-pq-composite-sigs]. 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
[I-D.ietf-lamps-cms-composite-sigs]. The choice of this composite
configuration is an experimental input, not a recommendation for
production deployment.
The object experiment applies [I-D.ietf-lamps-pq-composite-sigs] to
composite public keys and certificate signatures, and
[I-D.ietf-lamps-cms-composite-sigs] 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.
8.3. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 9]
Internet-Draft PQC for RPKI August 2026
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 [FIPS205], [RFC9909], and
[RFC9814]. 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.
8.4. 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 [FIPS186-5], which is already used for BGPsec
UPDATE signatures [RFC8608], and Ed25519 [RFC8032]. 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.
8.5. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 10]
Internet-Draft PQC for RPKI August 2026
+====================+======+===================+===================+
| Algorithm | Cat. | Key | Signature |
| | | representation | representation |
| | | used by model (B) | 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 | 1 | 897 | <=666 |
| (Falcon) | | | |
+--------------------+------+-------------------+-------------------+
| SLH-DSA-SHAKE-128s | 1 | 32 | 7856 |
+--------------------+------+-------------------+-------------------+
| SLH-DSA-SHAKE-192s | 3 | 48 | 16224 |
+--------------------+------+-------------------+-------------------+
Table 2
"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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 11]
Internet-Draft PQC for RPKI August 2026
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
[pqc-rpki-lab]. Measured values are implementation and environment
dependent and are not protocol requirements.
8.6. 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 [FIPS204], corresponding PKIX [RFC9881] and CMS
[RFC9882] 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 12]
Internet-Draft PQC for RPKI August 2026
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 [Doesburg2025]. 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 [Doesburg2025] and
repository-scale redesign work [pqRPKI] 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 13]
Internet-Draft PQC for RPKI August 2026
9. Experimental Object Encoding
9.1. Certificate and CRL Encoding
The composite certificate and CRL experiment follows the encodings in
[I-D.ietf-lamps-pq-composite-sigs]. 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 [RFC9881]; 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.
9.2. CMS Signed Object Encoding
The composite CMS experiment combines
[I-D.ietf-lamps-cms-composite-sigs] with the RPKI signed object
template in [RFC6488], as updated by [RFC9589]. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 14]
Internet-Draft PQC for RPKI August 2026
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.
9.3. Manifest Processing During Migration
A manifest covers the products of one CA instance at one publication
point, as specified by [RFC9286] and updated by [RFC9981]. 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 [RFC9286]. 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.
10. 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
[I-D.doesburg-sidrops-nullscheme] 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 15]
Internet-Draft PQC for RPKI August 2026
pqRPKI [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.
11. Repository Distribution Considerations
11.1. 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.
11.2. RRDP, rsync, and Erik Synchronization
RRDP [RFC8182] 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 [I-D.ietf-sidrops-rpki-erik-protocol] 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 16]
Internet-Draft PQC for RPKI August 2026
11.3. 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.
12. Experimental Results
12.1. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 17]
Internet-Draft PQC for RPKI August 2026
12.2. 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 [I-D.ietf-sidrops-rpki-ccr]. 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.
13. Implementation Status
This section records the status of the experiments at the time of
posting this Internet-Draft, using the reporting pattern described in
[RFC7942]. It is intended to assist IETF discussion and is to be
removed before publication as an RFC.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 18]
Internet-Draft PQC for RPKI August 2026
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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 19]
Internet-Draft PQC for RPKI August 2026
14. 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
Yoshikawa & Velvindron Expires 21 February 2027 [Page 20]
Internet-Draft PQC for RPKI August 2026
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 [RFC9881].
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 [I-D.ietf-lamps-pq-composite-sigs];
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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 21]
Internet-Draft PQC for RPKI August 2026
15. 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.
16. 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.
16.1. 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.
16.2. 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 [RFC8183], 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 22]
Internet-Draft PQC for RPKI August 2026
16.3. 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.
16.4. Operational Readiness
* Which PQC signature algorithms RIR CA teams and their HSM vendors
plan to support, on what firmware, API, certification, and
deployment timelines.
17. Informative References
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<https://www.rfc-editor.org/info/rfc6487>.
[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,
<https://www.rfc-editor.org/info/rfc6488>.
[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, <https://www.rfc-editor.org/info/rfc6916>.
[RFC7935] Huston, G. and G. Michaelson, Ed., "The Profile for
Algorithms and Key Sizes for Use in the Resource Public
Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
August 2016, <https://www.rfc-editor.org/info/rfc7935>.
[RFC8182] Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
DOI 10.17487/RFC8182, July 2017,
<https://www.rfc-editor.org/info/rfc8182>.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 23]
Internet-Draft PQC for RPKI August 2026
[RFC8209] Reynolds, M., Turner, S., and S. Kent, "A Profile for
BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", RFC 8209,
DOI 10.17487/RFC8209, September 2017,
<https://www.rfc-editor.org/info/rfc8209>.
[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,
<https://www.rfc-editor.org/info/rfc9286>.
[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,
<https://www.rfc-editor.org/info/rfc9582>.
[RFC9589] Snijders, J. and T. Harrison, "On the Use of the
Cryptographic Message Syntax (CMS) Signing-Time Attribute
in Resource Public Key Infrastructure (RPKI) Signed
Objects", RFC 9589, DOI 10.17487/RFC9589, May 2024,
<https://www.rfc-editor.org/info/rfc9589>.
[RFC9691] Martinez, C., Michaelson, G., Harrison, T., Bruijnzeels,
T., and R. Austein, "A Profile for Resource Public Key
Infrastructure (RPKI) Trust Anchor Keys (TAKs)", RFC 9691,
DOI 10.17487/RFC9691, December 2024,
<https://www.rfc-editor.org/info/rfc9691>.
[RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E.
Westerbaan, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Module-Lattice-Based Digital
Signature Algorithm (ML-DSA)", RFC 9881,
DOI 10.17487/RFC9881, October 2025,
<https://www.rfc-editor.org/info/rfc9881>.
[RFC9882] Salter, B., Raine, A., and D. Van Geest, "Use of the ML-
DSA Signature Algorithm in the Cryptographic Message
Syntax (CMS)", RFC 9882, DOI 10.17487/RFC9882, October
2025, <https://www.rfc-editor.org/info/rfc9882>.
[RFC9981] Harrison, T., Michaelson, G., and J. Snijders, "Resource
Public Key Infrastructure (RPKI) Manifest Number
Handling", RFC 9981, DOI 10.17487/RFC9981, May 2026,
<https://www.rfc-editor.org/info/rfc9981>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaussner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
Yoshikawa & Velvindron Expires 21 February 2027 [Page 24]
Internet-Draft PQC for RPKI August 2026
Algorithm (ML-DSA) for use in X.509 Public Key
Infrastructure", Work in Progress, Internet-Draft, draft-
ietf-lamps-pq-composite-sigs-19, 21 April 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
[I-D.ietf-lamps-cms-composite-sigs]
Ounsworth, M., Gray, J., Klaussner, J., and D. Van Geest,
"Composite Module-Lattice-Based Digital Signature
Algorithm (ML-DSA) for use in Cryptographic Message Syntax
(CMS)", Work in Progress, Internet-Draft, draft-ietf-
lamps-cms-composite-sigs-05, 22 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
cms-composite-sigs-05>.
[FIPS204] National Institute of Standards and Technology, "Module-
Lattice-Based Digital Signature Standard", FIPS 204,
August 2024, <https://doi.org/10.6028/NIST.FIPS.204>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource
Public Key Infrastructure (RPKI) Production Services",
RFC 8183, DOI 10.17487/RFC8183, July 2017,
<https://www.rfc-editor.org/info/rfc8183>.
[RFC8608] Turner, S. and O. Borchert, "BGPsec Algorithms, Key
Formats, and Signature Formats", RFC 8608,
DOI 10.17487/RFC8608, June 2019,
<https://www.rfc-editor.org/info/rfc8608>.
[RFC9323] Snijders, J., Harrison, T., and B. Maddison, "A Profile
for RPKI Signed Checklists (RSCs)", RFC 9323,
DOI 10.17487/RFC9323, November 2022,
<https://www.rfc-editor.org/info/rfc9323>.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 25]
Internet-Draft PQC for RPKI August 2026
[RFC9814] Housley, R., Fluhrer, S., Kampanakis, P., and B.
Westerbaan, "Use of the SLH-DSA Signature Algorithm in the
Cryptographic Message Syntax (CMS)", RFC 9814,
DOI 10.17487/RFC9814, July 2025,
<https://www.rfc-editor.org/info/rfc9814>.
[RFC9842] Meenan, P., Ed. and Y. Weiss, Ed., "Compression Dictionary
Transport", RFC 9842, DOI 10.17487/RFC9842, September
2025, <https://www.rfc-editor.org/info/rfc9842>.
[RFC9909] Bashiri, K., Fluhrer, S., Gazdag, S., Van Geest, D., and
S. Kousidis, "Internet X.509 Public Key Infrastructure --
Algorithm Identifiers for the Stateless Hash-Based Digital
Signature Algorithm (SLH-DSA)", RFC 9909,
DOI 10.17487/RFC9909, December 2025,
<https://www.rfc-editor.org/info/rfc9909>.
[I-D.ietf-sidrops-rpki-ccr]
Snijders, J., Bakker, B., Bruijnzeels, T., and T. Buehler,
"A Profile for Resource Public Key Infrastructure (RPKI)
Canonical Cache Representation (CCR)", Work in Progress,
Internet-Draft, draft-ietf-sidrops-rpki-ccr-11, 1 July
2026, <https://datatracker.ietf.org/doc/html/draft-ietf-
sidrops-rpki-ccr-11>.
[I-D.ietf-sidrops-aspa-profile]
Snijders, J., Azimov, A., Uskov, E., Bush, R., Housley,
R., and B. Maddison, "A Profile for Autonomous System
Provider Authorization", Work in Progress, Internet-Draft,
draft-ietf-sidrops-aspa-profile-29, 29 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-29>.
[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-07, 16 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
rpki-erik-protocol-07>.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 26]
Internet-Draft PQC for RPKI August 2026
[I-D.doesburg-sidrops-nullscheme]
Doesburg, D., "Null Scheme for Signed Objects in the
Resource Public Key Infrastructure (RPKI)", Expired and
archived, Work in Progress, Internet-Draft, draft-
doesburg-sidrops-nullscheme-00, 5 October 2025,
<https://datatracker.ietf.org/doc/html/draft-doesburg-
sidrops-nullscheme-00>.
[FIPS186-5]
National Institute of Standards and Technology, "Digital
Signature Standard (DSS)", FIPS 186-5, February 2023,
<https://doi.org/10.6028/NIST.FIPS.186-5>.
[FIPS205] National Institute of Standards and Technology, "Stateless
Hash-Based Digital Signature Standard", FIPS 205, August
2024, <https://doi.org/10.6028/NIST.FIPS.205>.
[Doesburg2025]
Doesburg, D., "Post-Quantum Cryptography for the RPKI",
June 2025, <https://www.sidnlabs.nl/en/news-and-blogs/
thesis-pqc-for-the-rpki>.
[pqRPKI] Li, W., Li, Y., and T. Chung, "pqRPKI: A Practical RPKI
Architecture for the Post-Quantum Era", arXiv 2603.06968,
March 2026, <https://arxiv.org/abs/2603.06968>.
[pqc-rpki-lab]
Yoshikawa, T., "pqc-rpki-lab experimental evidence
snapshot", 20 August 2026, <https://github.com/marokiki/
pqc-rpki-lab/releases/tag/draft-yoshikawa-sidrops-pqc-
rpki-02>.
Appendix A. 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 [pqc-rpki-lab],
which contains the corresponding scripts, raw outputs, and
environment metadata. The harness remains the durable record.
A.1. Reproducibility Metadata
The evidence snapshot cited by this revision is the GitHub release
draft-yoshikawa-sidrops-pqc-rpki-02 of [pqc-rpki-lab]. The
repository contains the scripts, raw outputs, and additional
environment metadata used for the measurements in this appendix.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 27]
Internet-Draft PQC for RPKI August 2026
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 [I-D.ietf-lamps-pq-composite-sigs].
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.
A.2. 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/ | 0.340326 | 0.002114 | 0.009792 | 0.000057 |
| SHA-256 | | | | |
+-----------+-------------+------------+---------------+----------+
| P-256/ | 0.012660 | 0.000332 | 0.034535 | 0.005361 |
| SHA-256 | | | | |
+-----------+-------------+------------+---------------+----------+
| 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 |
+-----------+-------------+------------+---------------+----------+
Table 3
Yoshikawa & Velvindron Expires 21 February 2027 [Page 28]
Internet-Draft PQC for RPKI August 2026
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.
A.3. 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 [I-D.ietf-lamps-pq-composite-sigs] does not define ML-DSA-87
with P-256.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 29]
Internet-Draft PQC for RPKI August 2026
+===========+==========+==========+========+=========+============+
| Composite | Sign | Verify | PubKey | Mean | Repository |
| | (s/100k) | (s/100k) | (B) | sig (B) | ratio |
+===========+==========+==========+========+=========+============+
| ML-DSA-44 | 26.0 | 8.3 | 1377 | 2491 | 3.16 |
| + P-256 | | | | | |
+-----------+----------+----------+--------+---------+------------+
| ML-DSA-65 | 45.6 | 11.9 | 2017 | 3380 | 4.09 |
| + P-256 | | | | | |
+-----------+----------+----------+--------+---------+------------+
| ML-DSA-87 | 59.4 | 32.8 | 2689 | 4730 | 5.40 |
| + P-384 | | | | | |
+-----------+----------+----------+--------+---------+------------+
Table 4
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.
A.4. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 30]
Internet-Draft PQC for RPKI August 2026
+=========================+=============+=============+=========+
| 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 |
+-------------------------+-------------+-------------+---------+
Table 5
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.
A.5. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 31]
Internet-Draft PQC for RPKI August 2026
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 |
+-----------------------------+------------------+
Table 6
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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 32]
Internet-Draft PQC for RPKI August 2026
+=================+======================+============+========+
| Suite | Model prediction (B) | Measured | Model |
| | | median (B) | error |
+=================+======================+============+========+
| RSA-2048 | 9146 | 4843 | +88.8% |
+-----------------+----------------------+------------+--------+
| ML-DSA-65 + | 33131 | 28855 | +14.8% |
| P-256 Composite | | | |
+-----------------+----------------------+------------+--------+
Table 7
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.
A.6. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 33]
Internet-Draft PQC for RPKI August 2026
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 | Generation wall |
| | | median (s) | 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 |
+------+--------------------+-----------------+------------------+
Table 8
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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 34]
Internet-Draft PQC for RPKI August 2026
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.
A.7. 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 [RFC9842] are not
included.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 35]
Internet-Draft PQC for RPKI August 2026
+===========+===========+===============+============+============+
| Algorithm | State | Local rsync | RRDP | Erik |
| | | exchanged (B) | response | response |
| | | | bodies (B) | 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 | 203,695 | 191,067 | 143,259 |
| | update | | | |
+-----------+-----------+---------------+------------+------------+
| RSA-2048 | 10% ROA | 370,906 | 413,520 | 303,738 |
| | churn | | | |
+-----------+-----------+---------------+------------+------------+
| 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 | 222,370 | 215,967 | 161,934 |
| | update | | | |
+-----------+-----------+---------------+------------+------------+
| ML-DSA-65 | 10% ROA | 1,163,068 | 1,469,604 | 1,095,900 |
| | churn | | | |
+-----------+-----------+---------------+------------+------------+
| Composite | Initial | 9,926,678 | 13,147,301 | 9,797,898 |
+-----------+-----------+---------------+------------+------------+
| Composite | Unchanged | 60,562 | 184 | 113 |
+-----------+-----------+---------------+------------+------------+
| Composite | One ROA | 169,476 | 145,451 | 109,048 |
| | update | | | |
+-----------+-----------+---------------+------------+------------+
| Composite | 10% ROA | 1,133,142 | 1,429,580 | 1,065,982 |
| | churn | | | |
+-----------+-----------+---------------+------------+------------+
Table 9
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
Yoshikawa & Velvindron Expires 21 February 2027 [Page 36]
Internet-Draft PQC for RPKI August 2026
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.
A.8. 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.
Appendix B. 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 37]
Internet-Draft PQC for RPKI August 2026
* 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.
Yoshikawa & Velvindron Expires 21 February 2027 [Page 38]
Internet-Draft PQC for RPKI August 2026
Authors' Addresses
Tomoki Yoshikawa
Kyoto University
Japan
Email: yoshikawa.tomoki.67i@st.kyoto-u.ac.jp
Loganaden Velvindron
cyberstorm.mu
Mauritius
Email: logan@cyberstorm.mu
Yoshikawa & Velvindron Expires 21 February 2027 [Page 39]