Post-Quantum Signature Algorithm Profile and Migration Considerations for the Resource Public Key Infrastructure (RPKI)
draft-yoshikawa-sidrops-pqc-rpki-01
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) | |
|---|---|---|---|
| Author | Tomoki Yoshikawa | ||
| Last updated | 2026-07-03 | ||
| 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-01
SIDROPS T. Yoshikawa
Internet-Draft Graduate School of Informatics, Kyoto University
Intended status: Standards Track 4 July 2026
Expires: 5 January 2027
Post-Quantum Signature Algorithm Profile and Migration Considerations
for the Resource Public Key Infrastructure (RPKI)
draft-yoshikawa-sidrops-pqc-rpki-01
Abstract
This document defines an initial experimental post-quantum signature
profile and migration design for the Resource Public Key
Infrastructure (RPKI). The profile uses Composite ML-DSA-65 with
ECDSA P-256 for RPKI certificates, CRLs, certification requests, and
CMS signed objects. The migration design introduces the composite
suite at CA boundaries through Mixed Certification Chains. It
preserves the existing RPKI object formats, repository system,
validation procedure, and router-facing VRP/RTR model. This revision
is intended for SIDROPS evaluation and does not update RFC 7935.
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 5 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
Yoshikawa Expires 5 January 2027 [Page 1]
Internet-Draft PQC for RPKI July 2026
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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Algorithm Profile . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Current Suite . . . . . . . . . . . . . . . . . . . . . . 5
6.2. Primary Experimental Candidate . . . . . . . . . . . . . 5
6.3. Additional Candidate Suites . . . . . . . . . . . . . . . 6
6.4. Classical Reference Points . . . . . . . . . . . . . . . 7
6.5. Algorithm Comparison . . . . . . . . . . . . . . . . . . 7
6.6. Algorithm Selection Rationale . . . . . . . . . . . . . . 8
7. Resource Certificate and CRL Profile . . . . . . . . . . . . 10
8. CMS Signed Object Profile . . . . . . . . . . . . . . . . . . 11
9. Signed Object Coverage . . . . . . . . . . . . . . . . . . . 11
10. Manifests and Repository Processing . . . . . . . . . . . . . 12
10.1. Manifest Scope During Migration . . . . . . . . . . . . 12
10.2. Parallel Publication Mechanics . . . . . . . . . . . . . 12
11. Relying Party Behavior . . . . . . . . . . . . . . . . . . . 13
12. Migration Considerations . . . . . . . . . . . . . . . . . . 14
12.1. Parallel Publication and Semantic Divergence . . . . . . 14
12.2. Composite Signatures . . . . . . . . . . . . . . . . . . 14
12.3. Mixed Certification Chains and Mixed-Tree Migration . . 15
13. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
14. Security Considerations . . . . . . . . . . . . . . . . . . . 17
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
16. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 19
16.1. Algorithm Selection . . . . . . . . . . . . . . . . . . 19
16.2. Migration Design . . . . . . . . . . . . . . . . . . . . 19
16.3. Operational Readiness . . . . . . . . . . . . . . . . . 20
17. Normative References . . . . . . . . . . . . . . . . . . . . 20
18. Informative References . . . . . . . . . . . . . . . . . . . 22
Appendix A. Preliminary Measurement Results . . . . . . . . . . 24
A.1. Measured Certificate and CRL Sizes . . . . . . . . . . . 24
A.2. Synthetic Repository Size Model . . . . . . . . . . . . . 25
A.3. Bulk Signing and Verification . . . . . . . . . . . . . . 26
A.4. Open Measurement Tasks . . . . . . . . . . . . . . . . . 27
Appendix B. Changes from -00 . . . . . . . . . . . . . . . . . . 28
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29
Yoshikawa Expires 5 January 2027 [Page 2]
Internet-Draft PQC for RPKI July 2026
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) would invalidate the long-term security
assumptions of the classical signature algorithms used today. This
document therefore describes a migration path away from CRQC-
vulnerable signature algorithms that can be tested before an
emergency transition is required.
The design goal of this document is conservative. RPKI already has a
well-defined architecture, repository system, validation procedure,
and router interface. This document keeps those layers intact. PQC
processing is introduced at the Certification Authority (CA),
repository, CMS signed object, and Relying Party (RP) validation
layers. Routers that consume Validated ROA Payloads (VRPs) through
the RPKI-Router Protocol (RTR) or local files are not expected to
process PQC signatures directly.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [BCP14] when, and only when, they appear in all capitals, as shown
here.
3. 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 currently accepted by an RPKI
implementation for production validation. 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.
PQC Suite: A Next Suite whose signature algorithm is intended to
remain secure against a CRQC.
Certificate Signature Algorithm: The algorithm used by the issuer to
sign a certificate or CRL.
Yoshikawa Expires 5 January 2027 [Page 3]
Internet-Draft PQC for RPKI July 2026
Subject Public Key Algorithm: The algorithm of the key carried in a
certificate's subjectPublicKeyInfo (SPKI).
Mixed Certification Chain: A certification path in which different
algorithm suites are used above and below a transition certificate.
Corresponding Products: RPKI products issued under different
algorithm suites that assert the same RPKI semantics. For ROAs, this
means the same set of VRPs, modulo local policy and trust anchor
selection.
Semantic Equivalence: A property of two validated RPKI outputs in
which their routing semantics are identical. For ROA-derived VRPs,
the comparison keys are prefix, maxLength, origin AS, and validation
source or trust anchor context. See also the Canonical Cache
Representation [I-D.ietf-sidrops-rpki-ccr].
Parallel Publication: A migration technique in which a CA publishes
corresponding products under both the Current Suite and the Next
Suite for an extended interval.
Composite Signature: A single signature algorithm construction that
combines a PQC algorithm and a traditional algorithm at the
cryptographic or encoding layer. Verification succeeds only when
every component signature validates.
4. Scope
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 CMS signed objects are treated as a single signed-
object algorithm profile; see the Signed Object Coverage section.
This document covers the RPKI signatures on BGPsec Router
Certificates, but does not define or change the BGPsec UPDATE
signature algorithm specified by [RFC8608].
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]. Readiness for BPKI trust-anchor key rollover is
nevertheless a migration dependency and is recorded as an Open Issue.
Yoshikawa Expires 5 January 2027 [Page 4]
Internet-Draft PQC for RPKI July 2026
5. Design Goals
The profile has the following goals.
* Preserve the existing RPKI architecture and repository model.
* 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.
* Preserve signature unforgeability if one component of the
composite suite is broken while the other component remains
secure.
* Support a prolonged Current Suite and Next Suite interval.
* Make downgrade, unsupported-algorithm, and semantic-divergence
cases observable by RPs and operators.
* Keep measurement and interoperability evidence reproducible
outside the protocol specification.
6. Algorithm Profile
6.1. Current Suite
The Current Suite remains RSA PKCS #1 v1.5 with SHA-256 as specified
by RFC 7935 until a separate transition timetable changes production
RPKI policy.
6.2. Primary Experimental Candidate
The primary Next Suite candidate in this revision is id-MLDSA65-
ECDSA-P256-SHA512, as specified by [I-D.ietf-lamps-pq-composite-sigs]
and [I-D.ietf-lamps-cms-composite-sigs]. It combines ML-DSA-65 with
ECDSA P-256 and requires both component signatures to validate. This
revision selects the composite construction and Mixed Certification
Chain as its migration design; deployment remains experimental until
CA and RP interoperability is demonstrated.
Yoshikawa Expires 5 January 2027 [Page 5]
Internet-Draft PQC for RPKI July 2026
An implementation experiment SHOULD process the composite public key
and certificate signatures according to
[I-D.ietf-lamps-pq-composite-sigs] and SHOULD process composite CMS
SignedData according to [I-D.ietf-lamps-cms-composite-sigs].
RPKI CAs participating in an isolated experiment MAY use the primary
composite suite for CA certificates, EE certificates, CRLs, and CMS
signed objects. They MUST NOT publish experimental objects into a
production repository or use production keys or TALs.
6.3. Additional Candidate Suites
ML-DSA-44 is a serious alternative to ML-DSA-65. It produces smaller
public keys and signatures and may sign and verify faster, which
matters in a system where every RP repeatedly fetches and validates
the entire global repository. It is not the selected PQC component
in this revision because this document currently uses NIST security
Category 3 as a conservative floor for a long-lived, globally
deployed suite; the Algorithm Selection Rationale discusses this
trade-off and the 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 primitive, PKIX, and CMS
specifications are defined by [FIPS205], [RFC9909], and [RFC9814].
They are not proposed as the initial suite because their signature
sizes and signing costs are substantially higher than ML-DSA in the
available measurements.
FN-DSA (Falcon), MAYO, SNOVA, and HAWK are additional candidates for
future evaluation. They are outside this profile 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
Algorithm Selection Rationale, 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 not
change the composite plus mixed-tree migration design selected by
this revision. A composite signature is a new algorithm from the
point of view of an RP: a validator that only supports the RSA
Current Suite cannot validate a composite object.
Yoshikawa Expires 5 January 2027 [Page 6]
Internet-Draft PQC for RPKI July 2026
6.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 represent the realistic lower bound for signature and
key sizes in the non-PQ universe: 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.
6.5. Algorithm Comparison
The table below summarizes the static parameters of the candidate and
reference algorithms, taken from the defining standards. These
values are properties of the algorithms themselves and are
independent of any implementation.
+=====================+======+============+=========+
| Algorithm | Cat. | PubKey (B) | Sig (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 |
+---------------------+------+------------+---------+
Table 1
"Cat." is the NIST security category; "n/a" marks classical reference
algorithms. The RSA-2048 public key size is the DER-encoded SPKI
payload, the other public key sizes are raw key encodings, and ECDSA
signature sizes vary slightly with DER encoding.
Yoshikawa Expires 5 January 2027 [Page 7]
Internet-Draft PQC for RPKI July 2026
Beyond static sizes, this document evaluates candidates along the
following dimensions: certificate and CRL size under the RPKI
profile; CMS signed object size; signing and verification cost under
the RP workload; repository size and distribution (RRDP and rsync)
impact; CA key rollover and publication cycle impact; HSM support;
and standardization and implementation maturity.
Three 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 the cost of a lattice
migration falls disproportionately on RPs rather than on CAs.
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. Third, FN-DSA
verification is fast, which is directly relevant to the RP workload
and supports keeping FN-DSA in the comparison set despite the
maturity concerns discussed below.
Preliminary 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 of this
revision (to be removed before publication) 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.
6.6. Algorithm Selection Rationale
This revision selects a composite suite because a global RPKI
migration should not depend exclusively on a newly deployed PQC
algorithm. The LAMPS construction accepts a composite signature only
when both component signatures validate. For a classical adversary,
existential unforgeability is therefore retained when either ML-
DSA-65 or ECDSA P-256 remains secure and the prehash construction
remains collision resistant. This provides a hedge against a
cryptanalytic break or an independent implementation defect affecting
one component during the transition.
This hedge 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.
Yoshikawa Expires 5 January 2027 [Page 8]
Internet-Draft PQC for RPKI July 2026
ML-DSA-65 is used as the PQC component of the primary experimental
suite because it has an existing FIPS signature specification
[FIPS204] and corresponding PKIX [RFC9881] and CMS [RFC9882]
algorithm identifier specifications, because implementations are
becoming widely available, and because Category 3 provides a
conservative security margin for a suite whose re-migration would be
a global, multi-year operation. It is not selected 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 small-PQ composite built on it, may
be a better use of the size budget [Doesburg2025]. This document
keeps ML-DSA-65 as the conservative default for experimentation,
keeps ML-DSA-44 in the measured comparison, and records the parameter
set choice as an Open Issue for SIDROPS.
ML-DSA-87 provides a higher-security comparison point, but its size
and performance costs make it unattractive as the general repository
suite.
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 candidate for future evaluation rather than a primary
candidate, 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.
* FN-DSA signing relies on floating-point Gaussian sampling, which
is difficult to implement in constant time; side-channel-resistant
implementations are an active research and engineering concern.
This is particularly relevant for CA signing keys held in HSMs.
Yoshikawa Expires 5 January 2027 [Page 9]
Internet-Draft PQC for RPKI July 2026
* 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. No production
RPKI CA or RP support has been demonstrated.
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
promoted are recorded as an Open Issue.
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.
7. Resource Certificate and CRL Profile
RPKI resource certificates and CRLs using the primary composite suite
MUST follow [I-D.ietf-lamps-pq-composite-sigs]. The SPKI
AlgorithmIdentifier of a subject using the composite suite MUST
contain id-MLDSA65-ECDSA-P256-SHA512, and its parameters MUST be
absent. A certificate or CRL signed by a composite-suite issuer MUST
use that identifier in its signatureAlgorithm field, with absent
parameters. A transition certificate signed by a Current Suite
issuer instead retains the issuer's Current Suite signatureAlgorithm
while carrying the composite identifier in the subject SPKI. Public
key and signature values MUST use the encodings defined for their
respective algorithms.
Resource certificate requests made under [RFC6487] for a composite-
suite subject MUST carry the same composite SPKI identifier and
encoding. A proof-of-possession signature in the request MUST use
the composite signature identifier and encoding.
Pure ML-DSA certificates and CRLs used for component measurements
follow [RFC9881], but pure ML-DSA is not the primary Next Suite
selected by this revision.
For RPKI CA certificates, the keyUsage extension MUST remain
consistent with the resource certificate profile. A CA certificate
that is used to issue certificates and CRLs requires keyCertSign and
cRLSign. An EE certificate used for an RPKI signed object requires
digitalSignature and MUST NOT be used as a CA certificate.
This document does not change the RPKI resource extension semantics,
certificate policy OID, certificate path validation procedure,
manifest processing rules, or CRL processing rules.
Yoshikawa Expires 5 January 2027 [Page 10]
Internet-Draft PQC for RPKI July 2026
8. CMS Signed Object Profile
RPKI signed objects using the primary composite suite MUST follow
[I-D.ietf-lamps-cms-composite-sigs] and the RPKI signed object
template defined in [RFC6488], as updated by [RFC9589].
The signatureAlgorithm field of SignerInfo MUST contain id-MLDSA65-
ECDSA-P256-SHA512. AlgorithmIdentifier parameters MUST be absent.
For this composite suite, the digestAlgorithms field of SignedData
and the digestAlgorithm field of SignerInfo MUST contain id-sha512.
The parameters field of that AlgorithmIdentifier MUST be absent. The
message-digest signed attribute MUST contain the SHA-512 digest of
the eContent.
The signedAttrs element remains REQUIRED for RPKI signed objects. In
accordance with [RFC6488] as updated by [RFC9589], it MUST contain
exactly one content-type attribute, one message-digest attribute, and
one signing-time attribute. The binary-signing-time attribute and
all other signed attributes MUST be absent. The RPKI signed object
profile restricts signedAttrs to those three attributes.
The CMS eContentType and eContent for ROAs, manifests, and other RPKI
signed objects are unchanged. Validators MUST apply the object-
specific validation rules after CMS signature validation exactly as
they do for the Current Suite.
9. 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, and one repository. This
document applies a single signature algorithm suite uniformly to all
of them. Migrating, for example, ROAs to a PQC suite while leaving
ASPA objects on RSA would create little benefit and considerable
complexity: the objects are protected by the same certification
chain, distributed through the same repository, and broken by the
same CRQC.
Changing the signature algorithm does not change an object's
eContentType, payload, or object-specific validation rules. 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.
Yoshikawa Expires 5 January 2027 [Page 11]
Internet-Draft PQC for RPKI July 2026
BGPsec UPDATE signatures are not RFC 6488 signed objects and are not
covered by this profile. BGPsec Router Certificates and their
covering CRLs and manifests are repository products and are covered,
as described in the Scope section.
10. Manifests and Repository Processing
10.1. Manifest Scope During Migration
A manifest covers the products of one CA instance at one publication
point, as specified by [RFC9286]. 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 Certification Chains 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.2. Parallel Publication Mechanics
This document does not define new payload encodings for manifests,
ROAs, or CRLs. Repository operators MAY publish Current Suite and
Next Suite products in parallel during an algorithm transition. A
repository that publishes parallel products MUST ensure that
manifests and CRLs are internally consistent within each suite.
During parallel publication, operators SHOULD provide a way to
identify corresponding products across suites for measurement and
debugging. This identification MAY be derived from publication point
structure, object names, CA hierarchy, or an implementation-specific
mapping. It is not a new on-wire RPKI object in this version.
Yoshikawa Expires 5 January 2027 [Page 12]
Internet-Draft PQC for RPKI July 2026
11. Relying Party Behavior
An RP that implements this document MUST be configurable with an
accepted algorithm policy covering certificate SPKI algorithms and
signature algorithms. The policy MUST be able to represent at least:
* Current Suite only;
* Current Suite plus Next Suite;
* Next Suite preferred with Current Suite fallback;
* Next Suite only.
An RP MUST reject a certificate whose SPKI algorithm or signature
algorithm is not in its configured policy. It MUST likewise reject a
CRL or signed object whose signature algorithm is not in that policy.
The rejection reason SHOULD be reported distinctly from syntax
errors, path validation failures, manifest failures, and object-
specific semantic failures.
An RP that processes Mixed Certification Chains MUST process each
certificate or CRL signatureAlgorithm independently and verify the
signature with the issuer's public key. It MUST NOT infer the
subject SPKI algorithm from the certificate signatureAlgorithm or
require those two fields to identify the same algorithm.
An RP that validates both Current Suite and Next Suite products
SHOULD perform semantic-equivalence checks for corresponding
products. For ROAs, this check compares the resulting VRP set by
prefix, maxLength, origin AS, and trust anchor context. The
Canonical Cache Representation [I-D.ietf-sidrops-rpki-ccr] provides a
suitable mechanism: if the ROAPayloadState hashes of two validation
runs match, the VRP sets consumed by routers are identical, and if
they differ, the decoded payload states identify the divergent VRPs.
If the Current Suite and Next Suite produce different routing
semantics, the RP SHOULD emit telemetry and SHOULD NOT silently merge
the divergent outputs.
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.
Yoshikawa Expires 5 January 2027 [Page 13]
Internet-Draft PQC for RPKI July 2026
12. Migration Considerations
The intended migration combines a composite signature suite with a
Mixed Certification Chain. A parent CA using the Current Suite
issues a child CA certificate whose SPKI contains the composite-suite
public key. The child CA then issues certificates and CRLs and signs
CMS objects with the composite suite. This moves one subtree at a
time without creating parallel production objects with potentially
different payloads.
Before a production subtree is switched, the composite profile and
the mixed-chain path must be supported by the issuing CA and by the
RP population. The transition therefore proceeds through
implementation, test repositories under test TALs, RP readiness
measurement, staged subtree migration, and eventual retirement of the
Current Suite.
12.1. Parallel Publication and Semantic Divergence
Parallel Publication is useful in test repositories for comparing a
Current Suite branch with a candidate branch. It is not the
preferred production transition because independent branches can
diverge through publication failures, timing skew, software defects,
or configuration drift. Experiments using parallel branches MUST
compare their resulting VRP sets. CCR [I-D.ietf-sidrops-rpki-ccr]
may be used as the common representation for that comparison.
12.2. Composite Signatures
Composite signatures [I-D.ietf-lamps-pq-composite-sigs]
[I-D.ietf-lamps-cms-composite-sigs] bind a classical and a PQC
signature to one object and one payload. This avoids cross-branch
semantic divergence and permits the classical component to protect
the object if the PQC component is found to have a security defect
while the classical component remains secure. Conversely, ML-DSA-65
protects against a CRQC when ECDSA P-256 no longer does. This hedge
is a primary reason for selecting a composite suite rather than a
pure PQC suite in this revision.
The LAMPS verification rule requires every component signature to
validate. An implementation MUST NOT accept the composite signature
when either component fails. A composite suite is nevertheless a new
algorithm to every RP and combines the size and processing cost of
its components. Its use therefore depends on stable PKIX and CMS
profiles and interoperable CA and RP implementations.
Yoshikawa Expires 5 January 2027 [Page 14]
Internet-Draft PQC for RPKI July 2026
12.3. Mixed Certification Chains and Mixed-Tree Migration
The parent signs the transition certificate using the algorithm
associated with the parent's key, while the child SPKI carries the
composite-suite key. Below that boundary, the child uses the
composite suite for its CA certificates, CRLs, and CMS signed
objects. The two algorithm fields are independent; an RP MUST
process each certificate or CRL signatureAlgorithm and verify the
signature with the issuer's public key.
This pattern requires no new RPKI object format. It does require RPs
to support both the transition certificate and the suite used below
it. A subtree switched before RP support is sufficiently deployed is
rejected by legacy RPs, so RP readiness is a precondition for each
production switch. CA implementations and HSMs must also support the
selected suite, and repository size, transfer, and validation costs
must be measured before deployment.
13. Implementation Status
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
It is intended to assist IETF discussion and is to be removed before
publication as an RFC.
An experimental repository, pqc-rpki-lab, was used to evaluate this
proposal. The evaluation is at an early stage; the lists below
distinguish what has actually run from what has not.
Implemented:
* Static algorithm metadata for the algorithms in the comparison
table.
* Primitive benchmarks using existing libraries, unified under a
single OpenSSL CLI code path with comparable-group metadata and an
automated results-validation guard.
* A recorded bulk measurement of 100,000 signing and 100,000
verification operations for RSA-2048, P-256, Ed25519, ML-DSA-
44/65/87, and FN-DSA-512, plus sequential component measurements
for ten two-algorithm combinations, with conditions documented
alongside the results (see Appendix A).
* Synthetic repository impact estimator.
* Local cache size collector.
Yoshikawa Expires 5 January 2027 [Page 15]
Internet-Draft PQC for RPKI July 2026
* VRP semantic equivalence checker for CSV/JSON fixtures; on the
current fixtures, the classical-side and PQC-side normalized VRP
hashes match. Its interim hash is computed over canonical JSON
and is not a CCR hash; results from it are not labeled as CCR
output.
* Mixed-tree test structure generation (RSA trust anchor, ML-DSA-65
child CA SPKI, child products keyed consistently); structural
consistency checks pass.
* Certificate and CRL generation with OpenSSL 3.6.2 for RSA-2048,
P-256, Ed25519, ML-DSA-44/65/87, FN-DSA-512, SLH-DSA-SHAKE-128s,
and SLH-DSA-SHAKE-192s, using the applicable PKIX profiles where
standardized.
* RFC 6488 ML-DSA-65 CMS SignedData generation through the OpenSSL
CMS API with explicit SHA-512, independently cross-checked by a
minimal DER assembler, including complete ROA and manifest
fixtures.
* Repeated 32-byte, 512-byte, 2-KiB, and 8-KiB primitive
measurements, with 1000 operations in each of 10 repetitions, key-
generation timing, variance, and process peak-RSS observations.
* Isolated local-rsync validation with pinned unmodified Routinator,
rpki-client, and FORT containers. All accepted the RSA baseline
and rejected the ML-DSA-65 trust anchor or certificate before
processing its complete repository.
Not yet implemented or incomplete:
* Complete ML-DSA-44, ML-DSA-87, and SLH-DSA CMS signed-object
fixtures.
* Acceptance by a validator extended for this profile and
corresponding Routinator or other validator patch evaluation.
* Krill integration for production-like CA issuance, manifest and
ROA signing, and publication.
* A complete mixed-tree repository accepted by an extended RP; the
current mixed-tree fixture is structural.
* RRDP and rsync impact measurement with real object corpora.
* CCR-based semantic equivalence testing across suites, using real
RP output rather than fixtures.
Yoshikawa Expires 5 January 2027 [Page 16]
Internet-Draft PQC for RPKI July 2026
* FN-DSA measurement through the same OpenSSL EVP path used for the
other algorithms (current FN-DSA numbers come from liboqs
components).
* Measurement of actual composite encodings per the LAMPS composite
specifications (current composite numbers are sequential component
lower bounds).
* HSM performance and support investigation.
The highest-priority implementation gap is generation and validation
of the selected Composite ML-DSA objects, followed by acceptance by
an RP extended for the profile and production-like CA support in
Krill or equivalent software. The complete pure ML-DSA-65 objects
and unmodified-validator rejection baseline provide component-level
inputs for that work, but do not establish composite
interoperability.
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.
Downgrade and inconsistent suite selection are primary concerns
during a long transition. An RP that supports both Current Suite and
Next Suite products MUST make its algorithm acceptance policy
explicit. It MUST NOT silently accept a Current Suite product as
equivalent to a missing or invalid Next Suite product when local
policy requires the Next Suite. 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 PQC suites coexist.
Parallel publication introduces the possibility of semantic
divergence. For example, the RSA branch and the PQC branch might
contain different ROA payloads, stale manifests, or different CRL
state. Validators SHOULD detect and report these cases rather than
silently selecting one branch without operator visibility; see the
Migration Considerations section.
Yoshikawa Expires 5 January 2027 [Page 17]
Internet-Draft PQC for RPKI July 2026
Mixed Certification Chains introduce the risk of confusing the
Certificate Signature Algorithm with the Subject Public Key
Algorithm. An implementation that assumes the two are equal may
accept invalid chains or reject valid ones. Implementations MUST
process each certificate or CRL signatureAlgorithm independently,
verify the signature with the issuer's public key, and process the
subject SPKI algorithm as a separate field.
Validators that do not support a Next Suite face a fail-open versus
fail-closed choice: treating unsupported-algorithm objects as absent
(potentially discarding protections the CA intended to publish) or
treating them as errors (potentially discarding an entire publication
point). Neither behavior is safe in all situations; what matters is
that the behavior is explicit, configurable, and observable,
consistent with the "unknown algorithm" handling direction of RFC
6916. How mixed deployments with unsupported validators should be
handled at internet scale remains an Open Issue.
Larger public keys, signatures, certificates, CRLs, and CMS objects
enlarge the repository fetch and validation attack surface. 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. Implementations SHOULD enforce resource limits and
telemetry for object size, number of objects, validation time, and
memory use. Operators SHOULD evaluate RRDP snapshot and delta sizes
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 signs with a leaky implementation is not protected.
Side-channel risk is algorithm dependent: FN-DSA's floating-point
Gaussian sampling is a known hard case for constant-time
implementation, which is one reason this document sequences FN-DSA
after ML-DSA.
ML-DSA uses randomized (hedged) signing by default. CA
implementations and HSMs MUST use cryptographically appropriate
randomness and SHOULD follow the operational guidance in RFC 9881 and
RFC 9882. Randomness failures during signing weaken the hedge
against side-channel and fault attacks; purely deterministic signing
is not preferred on platforms where such attacks are a concern.
Yoshikawa Expires 5 January 2027 [Page 18]
Internet-Draft PQC for RPKI July 2026
Algorithm confusion is possible if AlgorithmIdentifier parameters,
SignerInfo digestAlgorithm, CMS signed attributes, or certificate
SubjectPublicKeyInfo encodings are inconsistently handled.
Implementations MUST reject malformed AlgorithmIdentifier encodings
and MUST follow the parameter rules of the referenced LAMPS
specifications.
Composite signatures may protect against failures in one component
algorithm only when every component is verified and the other
component and the prehash construction remain secure. Component keys
MUST NOT be reused as standalone keys or in other composite
combinations, as required by [I-D.ietf-lamps-pq-composite-sigs].
Reuse can enable stripping and cross-protocol attacks. A shared
implementation defect, a combiner or parser 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.
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. Open Issues
The following issues require additional SIDROPS discussion and
implementation evidence. In particular, this draft should not
promote the experimental composite suite to a production requirement
until extended validator behavior is measured.
16.1. Algorithm Selection
* Whether the final standards-track profile should retain the ML-
DSA-65 and ECDSA P-256 component pair selected for this
experiment, or use another LAMPS Composite ML-DSA combination.
* 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
* Whether composite signatures combined with mixed-tree migration
are the appropriate production transition design, based on
implementation, interoperability, repository impact, and RP-
readiness evidence.
Yoshikawa Expires 5 January 2027 [Page 19]
Internet-Draft PQC for RPKI July 2026
* How RP-side readiness should be measured before any production CA
switches suites under a mixed-tree migration, given that a
switched subtree is invisible to non-upgraded RPs.
* How to handle validators that do not support the Next Suite in
mixed deployments (fail-open versus fail-closed, and reporting).
* How to define a transition timetable and readiness metrics, and
whether that work should update or replace RFC 6916.
* 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.
16.3. Operational Readiness
* Which PQC signature algorithms RIR CA teams and their HSM vendors
plan to support, on what firmware, API, certification, and
deployment timelines.
* Whether claimed HSM support uses a general-purpose CPU
implementation within the HSM boundary or native hardware or FPGA
acceleration, and how those implementation choices affect key
generation, signing latency, throughput, side-channel properties,
and operational capacity.
17. Normative References
[BCP14] Best Current Practice 14,
<https://www.rfc-editor.org/info/bcp14>.
At the time of writing, this BCP comprises the following:
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.
Yoshikawa Expires 5 January 2027 [Page 20]
Internet-Draft PQC for RPKI July 2026
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012,
<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>.
[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>.
Yoshikawa Expires 5 January 2027 [Page 21]
Internet-Draft PQC for RPKI July 2026
[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>.
[I-D.ietf-lamps-pq-composite-sigs]
Ounsworth, M., Gray, J., Pala, M., Klaussner, J., and S.
Fluhrer, "Composite Module-Lattice-Based Digital Signature
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>.
18. Informative References
[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>.
Yoshikawa Expires 5 January 2027 [Page 22]
Internet-Draft PQC for RPKI July 2026
[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>.
[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>.
[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-27, 19 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
aspa-profile-27>.
Yoshikawa Expires 5 January 2027 [Page 23]
Internet-Draft PQC for RPKI July 2026
[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] al., W. L. E., "pqRPKI: A Practical RPKI Architecture for
the Post-Quantum Era", March 2026,
<https://arxiv.org/abs/2603.06968>.
[pqc-rpki-lab]
Yoshikawa, T., "pqc-rpki-lab experimental harness", July
2026, <https://github.com/marokiki/pqc-rpki-
lab/releases/tag/draft-yoshikawa-sidrops-pqc-rpki-01>.
Appendix A. Preliminary Measurement Results
This appendix records preliminary measurements referenced by the
Algorithm Comparison 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. This appendix is to be removed before publication as an
RFC; the harness remains the durable record.
A.1. Measured Certificate and CRL Sizes
RFC 6487-profiled certificates (including RFC 3779 resource
extensions) and CRLs generated with the OpenSSL 3.6.2 default
provider:
Yoshikawa Expires 5 January 2027 [Page 24]
Internet-Draft PQC for RPKI July 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 2
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.
A.2. Synthetic Repository Size Model
First-order repository size ratios relative to the RSA-2048 baseline,
computed by applying static public key and signature sizes to a size
model of the current global repository. These are model outputs, not
full-repository measurements:
Yoshikawa Expires 5 January 2027 [Page 25]
Internet-Draft PQC for RPKI July 2026
+====================+==================+
| 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-87 | 5.28 |
+--------------------+------------------+
| SLH-DSA-SHAKE-128s | 6.85 |
+--------------------+------------------+
| SLH-DSA-SHAKE-192s | 13.38 |
+--------------------+------------------+
Table 3
A.3. Bulk Signing and Verification
Wall-clock seconds for 100,000 signing operations and 100,000
verification operations:
+=================================+===============+=================+
| Algorithm | Sign (s/100k) | Verify (s/100k) |
+=================================+===============+=================+
| RSA-2048/SHA-256 | 34.3 | 1.0 |
+---------------------------------+---------------+-----------------+
| P-256/SHA-256 | 1.3 | 3.5 |
+---------------------------------+---------------+-----------------+
| Ed25519 | 1.7 | 4.0 |
+---------------------------------+---------------+-----------------+
| ML-DSA-44 | 25.1 | 5.0 |
+---------------------------------+---------------+-----------------+
| ML-DSA-65 | 40.5 | 7.7 |
+---------------------------------+---------------+-----------------+
| ML-DSA-87 | 47.9 | 11.7 |
+---------------------------------+---------------+-----------------+
| FN-DSA-512 | 10.5 | 1.6 |
+---------------------------------+---------------+-----------------+
| RSA-2048 + P-256 (components) | 35.3 | 4.5 |
+---------------------------------+---------------+-----------------+
Yoshikawa Expires 5 January 2027 [Page 26]
Internet-Draft PQC for RPKI July 2026
| RSA-2048 + Ed25519 | 35.6 | 5.1 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| RSA-2048 + ML-DSA-44 | 59.2 | 5.8 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| RSA-2048 + ML-DSA-65 | 74.4 | 8.4 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| RSA-2048 + ML-DSA-87 | 81.1 | 12.7 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| RSA-2048 + FN-DSA-512 | 44.6 | 2.6 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| P-256 + ML-DSA-44 | 26.3 | 8.4 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| P-256 + ML-DSA-65 | 41.8 | 10.9 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| P-256 + ML-DSA-87 | 50.0 | 15.3 |
| (components) | | |
+---------------------------------+---------------+-----------------+
| P-256 + FN-DSA-512 | 12.1 | 5.1 |
| (components) | | |
+---------------------------------+---------------+-----------------+
Table 4
Conditions: Apple M4, single thread, OpenSSL 3.6.2 invoked through an
EVP C loop, 32-byte fixed message, 100,000 iterations per data point,
one recorded run, excluding key generation, I/O, and CMS/X.509
construction. Component-combination rows execute both operations
sequentially in one process; they are lower bounds and include no
composite encoding or CMS/X.509 overhead. FN-DSA-512 was measured
through liboqs 0.15.0 rather than the OpenSSL EVP path, so its rows
carry an additional comparability caveat. A single-host, single-run
measurement does not establish a general performance ordering.
A.4. 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-repository validation
impact; RRDP snapshot/delta and rsync transfer impact.
Yoshikawa Expires 5 January 2027 [Page 27]
Internet-Draft PQC for RPKI July 2026
* Full-validator memory footprint. The repeated primitive sweep
records process peak RSS, but this is not a repository-validation
measurement.
* HSM performance and support.
Appendix B. Changes from -00
This section is to be removed before publication as an RFC.
* Changed the primary experimental Next Suite from pure ML-DSA-65 to
the composite id-MLDSA65-ECDSA-P256-SHA512 signature suite.
* Added comparison material for ML-DSA-44, ML-DSA-87, ECDSA P-256,
Ed25519, FN-DSA/Falcon, and SLH-DSA, including preliminary size
and performance measurements.
* Reworked the migration strategy from a primarily parallel-
publication model to a mixed-tree migration model toward a
composite signature suite.
* Clarified that BGPsec Router Certificates are in scope, while
BGPsec UPDATE signatures are out of scope.
* Unified the treatment of RPKI signed objects covered by RFC 6488,
including manifests, ROAs, ASPA objects, RSCs, and TAK objects.
* Added terminology for Certificate Signature Algorithm, Subject
Public Key Algorithm, and Mixed Certification Chain.
* Expanded the security considerations for composite signatures,
mixed-chain validation, downgrade behavior, unsupported
validators, resource consumption, and implementation risks.
* Added Implementation Status and Appendix A with preliminary
implementation and measurement results.
* Clarified that this document requests no IANA actions.
* Updated Open Issues to focus on unresolved algorithm-selection,
migration-design, and operational-readiness questions.
Acknowledgements
The author thanks Job Snijders, Dirk Doesburg, Loganaden Velvindron,
and Ties de Kock for their reviews and comments. The author also
thanks the SIDROPS and LAMPS communities for the specifications and
implementation work that make this experiment possible.
Yoshikawa Expires 5 January 2027 [Page 28]
Internet-Draft PQC for RPKI July 2026
Author's Address
Tomoki Yoshikawa
Graduate School of Informatics, Kyoto University
Email: yoshikawa.tomoki.67i@st.kyoto-u.ac.jp
Yoshikawa Expires 5 January 2027 [Page 29]