Graduate School of Informatics, Kyoto University

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

Routing SIDROPS RPKI PQC ML-DSA SLH-DSA SIDROPS 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.

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.

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 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the terminology of the RPKI architecture , the resource certificate profile , the RPKI signed object template , the RPKI algorithm agility procedure , and the RPKI algorithm profile . Current Suite: The algorithm suite 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. 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 . 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.

Scope This document applies to RPKI resource certificates, CRLs, certification requests, BGPsec Router Certificates , and the CMS signed objects that reuse the RPKI signed object template , including manifests , ROAs , Signed Checklists (RSC) , ASPA objects , and Trust Anchor Key (TAK) objects . The 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 . This document does not specify changes to RTR, TAL formats, RRDP , rsync, the RPKI Certificate Policy, or the BPKI used to authenticate provisioning and publication relationships established through . Readiness for BPKI trust-anchor key rollover is nevertheless a migration dependency and is recorded as an Open Issue.

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.

Algorithm Profile

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.

Primary Experimental Candidate The primary Next Suite candidate in this revision is id-MLDSA65-ECDSA-P256-SHA512, as specified by and . 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. An implementation experiment SHOULD process the composite public key and certificate signatures according to and SHOULD process composite CMS SignedData according to . 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.

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 , , and . 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.

Classical Reference Points To relativize the cost of PQC candidates, this document uses two compact classical algorithms as non-normative reference points: ECDSA P-256 with SHA-256 , which is already used for BGPsec UPDATE signatures , and Ed25519 . Neither is a CRQC-resistant algorithm, and neither is proposed here as an RPKI suite. They 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.

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

"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. 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 . Measured values are implementation and environment dependent and are not protocol requirements.

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. ML-DSA-65 is used as the PQC component of the primary experimental suite because it has an existing FIPS signature specification and corresponding PKIX and CMS 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 . 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 and repository-scale redesign work 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.

• 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.

Resource Certificate and CRL Profile RPKI resource certificates and CRLs using the primary composite suite MUST follow . 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 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 , 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.

CMS Signed Object Profile RPKI signed objects using the primary composite suite MUST follow and the RPKI signed object template defined in , as updated by . 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 as updated by , 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.

Signed Object Coverage Manifests , ROAs , Signed Checklists , ASPA objects , TAK objects , and any future object types built on the RFC 6488 template share one CMS structure, one EE certificate model, 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 . 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 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.

Manifests and Repository Processing

Manifest Scope During Migration A manifest covers the products of one CA instance at one publication point, as specified by . The manifest is signed with a one-time-use EE certificate issued by that CA. Its fileList contains the certificates issued and published by that CA, the CA's current CRL, and signed objects whose embedded EE certificates were issued by that CA. The relevant RP check is therefore issuer and publication-scope consistency, not equality between the manifest signing key and product keys. An RP validates the manifest EE certificate under the associated CA, verifies each listed certificate, CRL, or signed object under that same CA instance as required by its object profile, and checks the publication point, file name, and file hash according to . A shared publication point can contain products from multiple CA instances during key rollover, but each manifest covers only its associated CA instance. Mixed 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.

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.

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 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.

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.

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 may be used as the common representation for that comparison.

Composite Signatures Composite signatures 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.

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.

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 . 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.
• 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.
• 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.

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. 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. 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 . 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.

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.

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.

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.

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.
• 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 , 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.

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.

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

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 , 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.

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:

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

The P-256 and Ed25519 rows use the same RFC 6487 structure and resource extensions as the other rows, but are classical comparison algorithms rather than RFC 7935 suites. The FN-DSA-512 row uses the experimental Falcon-512 OID and encoding from oqs-provider 0.11.0-rc1 with liboqs 0.15.0; it is a measured experimental encoding, not a final FN-DSA PKIX profile. Falcon signatures are variable length, so its certificate and CRL sizes can vary between runs.

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:

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

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
RSA-2048 + Ed25519 (components)	35.6	5.1
RSA-2048 + ML-DSA-44 (components)	59.2	5.8
RSA-2048 + ML-DSA-65 (components)	74.4	8.4
RSA-2048 + ML-DSA-87 (components)	81.1	12.7
RSA-2048 + FN-DSA-512 (components)	44.6	2.6
P-256 + ML-DSA-44 (components)	26.3	8.4
P-256 + ML-DSA-65 (components)	41.8	10.9
P-256 + ML-DSA-87 (components)	50.0	15.3
P-256 + FN-DSA-512 (components)	12.1	5.1

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.

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.
• Full-validator memory footprint. The repeated primitive sweep records process peak RSS, but this is not a repository-validation measurement.
• HSM performance and support.

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.