Considerations for Incremental Validation in RPKI Relying Parties

3.1. Repository Synchronization and Validation

RPKI repository synchronization and validation address different tasks. Repository synchronization updates the local set of repository data, while validation determines which objects are valid under the applicable RPKI specifications and derives validated payloads from valid payload-carrying signed objects. The RPKI Repository Delta Protocol (RRDP) [RFC8182] supports incremental synchronization through delta files when applicable, allowing an RP to retrieve repository changes without retrieving a complete repository snapshot for every update. However, reducing the amount of data transferred during synchronization does not necessarily reduce the amount of validation work performed afterward.¶

For example, consider a CA publication point containing many RPKI objects, including ROAs. When a ROA changes, the corresponding manifest must reflect the current object set and the hash of the changed object. The RP needs to process the current manifest and check the objects it references against the current repository data. Even if most other objects referenced by the manifest remain unchanged, an RP that performs full validation after each synchronization cycle may repeat parsing and decoding, cryptographic signature verification, certificate and signed-object validation, and validated payload generation for those unchanged objects. Similar repeated processing may occur for subordinate CA certificates and objects in other parts of the RPKI tree.¶

3.2. Operational Impact

Repeated validation processing can affect RP operation in several ways:¶

• Validation latency and payload freshness: Validation processing contributes to the time between the availability of updated repository data and the production of updated validated payloads. Even when repository synchronization completes quickly, repeated validation work may delay the availability of the resulting payloads. Reducing unnecessary validation work may shorten validation cycles and enable RPs to validate more frequently, thereby improving validated payload freshness.¶

• Computational and memory resource consumption: Repeated parsing, cryptographic verification, and other validation operations can increase CPU consumption. Processing large numbers of objects may also increase transient memory requirements. At the same time, retaining cached validation state introduces its own memory, storage, and maintenance costs. The benefits of incremental validation therefore depend not only on the processing time avoided, but also on the resources required to maintain and use the cached state.¶

• Growth in RPKI data and future cryptographic transitions: As the number and size of RPKI objects increase, the amount of work performed during a full validation cycle may also increase. This can place additional pressure on validation latency and computational resources, particularly when only a portion of the repository changes between successive validation cycles. In addition, a future transition to post-quantum cryptography (PQC), if adopted for RPKI, may change cryptographic verification costs, signature sizes, and other processing requirements. These potential changes provide an additional reason to consider approaches that avoid unnecessary repeated processing.¶

6.1. Signature-Verification Result Caching

Basic approach. Signature-verification result caching retains the result of a previously successful cryptographic signature verification for possible reuse in a later validation cycle. It aims to avoid repeating the cryptographic computation when the same verification operation is encountered again.¶

Cached information. An implementation using this approach needs to retain sufficient information to identify a signature-verification operation and its result. Such information may include:¶

• The signed input used by the signature-verification operation, or its digest where applicable.¶

• The signature value.¶

• The public key used for verification.¶

• The signature algorithm and its relevant parameters.¶

• The successful verification result.¶

Reuse conditions. A cached successful result can be reused only when the current verification operation uses the same signed input, signature value, public key, algorithm, and relevant parameters as the operation recorded in the cache. If no matching successful result exists, or any of these inputs differs, the RP needs to perform the cryptographic signature verification again.¶

Checks still required. Reusing a signature-verification result does not establish that the RPKI object is valid. The RP must still perform the other applicable validation checks for the object under the current validation context. Depending on the object type, these checks may include certificate and signed-object validity intervals, certificate revocation status, resource authorization, consistency with the current manifest, and other requirements defined by the applicable RPKI specifications. A cached signature-verification result cannot replace these checks or determine whether the object can contribute to the current validated payload output.¶

Applicability and limitations. This approach can be applied to signature-verification operations for different RPKI object types without requiring the RP to cache the complete validation state of each object. Its main benefit is avoiding repeated cryptographic computations when the verification inputs remain unchanged. However, it does not, by itself, avoid the parsing and decoding needed to obtain the verification inputs, other object-validation checks, or validated payload generation. Its benefit may be greater when signature verification accounts for a substantial share of the total validation cost. A future transition to post-quantum cryptography (PQC) may change signature-verification costs and could increase the value of this approach if verification becomes more computationally expensive.¶

6.2. Object-Validation-State Caching

Basic approach. Object-validation-state caching reuses the validation result previously computed for an individual RPKI object. When the object and the conditions affecting its validation remain unchanged, an RP can reuse the cached result instead of repeating object parsing, cryptographic signature verification, and other validation processing that is no longer necessary. This approach allows an RP to reuse the results for unchanged objects even when other objects in the same publication point have changed.¶

Cached information. An implementation using this approach needs to retain sufficient information to identify the object, determine the context under which it was validated, and recover its previous validation result. Such information may include:¶

• An identifier for the object.¶

• The identity of the parent CA and its effective IP address and AS number resources under which the object was validated.¶

• The relevant validity intervals.¶

• The serial number of the certificate whose revocation status affects the object.¶

• The previous validation status and, for an object that failed validation, the failure reason when needed to determine whether the cause of failure has changed.¶

• For a valid manifest, the filenames and corresponding hashes of the objects it lists.¶

• For a valid CRL, the serial numbers of revoked certificates.¶

• For valid payload-carrying objects, the derived validated payload, such as VRPs or VAPs, as applicable. For valid subordinate CA certificates, the effective resources needed to continue processing their publication points.¶

Reuse conditions. A cached validation result can be reused when the current object corresponds to the cached object, is included in the current manifest with content matching the hash specified in that manifest, and is reached through a parent CA whose identity and effective resources match those associated with the cached result.¶

Checks still required. Before using the cached result, the RP needs to check the object's relevant validity intervals against the current validation time and consult the current valid CRL to determine whether the relevant certificate is revoked. If a previously valid object is no longer valid at the current validation time, or the relevant certificate is revoked, the cached successful result cannot be used to treat the object as valid in the current validation cycle. If a previous validation failure occurred because the validation time was earlier than the object's notBefore time, and the current time has since entered its validity interval, the object needs to be fully validated before it can be treated as valid. Similarly, if a previous failure was caused by certificate revocation and the current valid CRL no longer lists the relevant certificate as revoked, the object needs to be validated again before it can be treated as valid.¶

Use of cached results. After the required checks succeed, the cached result can be used in the current validation cycle. For a valid payload-carrying object, its cached validated payload can contribute to the current output. For a valid subordinate CA certificate, the RP can use its effective resources to continue processing the subordinate CA's publication point, where the applicability of cached results must be determined separately.¶

Applicability and limitations. Object-validation-state caching can reduce repeated processing for individual objects without requiring an entire publication point to remain unchanged. Its effectiveness depends on how frequently cached object results remain applicable and on the cost of maintaining and checking the associated state. It requires the RP to determine reuse eligibility for each object and to account for changes in the object's parent CA context, validity, and revocation status.¶

6.3. Manifest-/Publication-Point-Level Reuse

Basic approach. A CA publishes its RPKI objects at a publication point (PP). The manifest associated with the PP identifies the expected set of published objects and records their hashes. Although the manifest is an object and the PP is a publication location, both are directly associated with the set of objects published by the CA. This document therefore discusses reuse of validation state for this set as one design category, referred to as manifest-/publication-point-level reuse. This approach treats the validation state associated with a CA's PP as a unit for reuse. When the relevant inputs and validation context remain unchanged, an RP can reuse the cached state for the entire PP instead of repeating full validation of the manifest and each object. This can avoid substantial processing when a PP remains unchanged between validation cycles.¶

Cached information. An implementation using this approach needs to retain sufficient state to determine whether the cached PP result remains applicable and to reconstruct the result for the current validation cycle. Such state may include:¶

• The identity of the CA certificate and the effective IP address and AS number resources under which the PP was validated.¶

• The identity and validity interval of the manifest and CRL.¶

• For each object listed in the manifest, its identity, validation status, and relevant validity interval. A failure reason may also be retained when it helps determine whether a previous validation failure can be resolved in a later cycle.¶

• For valid payload-carrying objects, the derived validated payload. For valid subordinate CA certificates, the effective resources needed to continue processing their PPs.¶

Reuse conditions. Whole-PP reuse can be considered when the following conditions hold:¶

• The CA certificate accepted in the current top-down validation corresponds to the CA certificate associated with the cached PP state.¶

• The current effective resources of the CA match those recorded in the cached state.¶

• The current manifest and CRL are unchanged from their cached versions and remain valid at the current validation time.¶

• All objects listed in the current manifest are present in the current repository, and their contents match the hashes recorded in the manifest.¶

Checks still required. Even when the conditions for whole-PP reuse hold, the RP needs to check the validity intervals of the cached objects against the current validation time. An object that is no longer valid at the current validation time cannot contribute to the current validated payload output. If a previous validation failure occurred only because the validation time was earlier than the object's notBefore time, and the current time has since entered its validity interval, the object needs to be fully validated before it can be treated as valid. These checks allow time-dependent changes to be handled without requiring full validation of every object in the PP.¶

Use of cached results. After these checks, the cached validated payloads of objects that remain valid can contribute to the current output. Valid subordinate CA certificates can be used to continue top-down processing of their respective PPs. The RP needs to determine separately whether each subordinate CA's cached validation state remains applicable; reuse of a parent PP does not establish that its subordinate PPs can also be reused.¶

Applicability and limitations. This approach can avoid repeated validation work across an unchanged PP, but it requires the RP to retain and check sufficient state to determine whether the cached result remains applicable. Its effectiveness depends on how frequently PPs remain unchanged between validation cycles and on the cost of maintaining the associated cached state.¶

6.4. Hybrid Approaches

Basic approach. Hybrid approaches can combine publication-point-level reuse and object-validation-state caching. They are useful when a CA's publication point has changed, but many of its published objects remain unchanged. For example, when a manifest is updated to reflect changes to a small number of ROAs, the previous validation result for the entire PP cannot be reused as the result for the current publication state. However, the validation results of unchanged ROAs may still be reusable.¶

Reuse-path selection. An RP can first determine whether the conditions for whole-PP reuse described in Section 5.3 are satisfied:¶

• Whole-PP reuse: If the CA certificate, effective resource context, manifest, and CRL remain unchanged and the other reuse conditions hold, the RP can reuse the cached validation state for its entire PP.¶

• Full validation: If the CA certificate identity or effective resource context has changed, the affected PP needs to be fully validated under the current context.¶

• Object-level reuse: If the CA identity and effective resource context remain unchanged but the manifest or CRL has changed, the RP can instead process the current manifest and CRL and attempt object-level reuse. The current manifest and CRL must be valid for the PP to be processed as valid in the current validation cycle.¶

Object-level reuse and revalidation. When object-level reuse is used, the current manifest determines the set of objects to be processed. For each object in that set, the RP can reuse its cached validation result if the object matches the cached object. The RP must check the current validity intervals and revocation status as applicable. Previously failed objects must also be revalidated when the condition that caused the failure no longer applies, such as when an object enters its validity interval or a previously revoked certificate is no longer listed as revoked in the current valid CRL. Objects that are new, have changed, or do not satisfy the reuse conditions need to be fully validated. Objects no longer included in the current manifest do not contribute to the current validated payload output.¶

Use of cached results. After the required checks succeed, cached validated payloads can contribute to the current output, and valid subordinate CA certificates can be used to continue processing their publication points.¶

Applicability and limitations. Combining publication-point-level and object-level reuse allows an RP to avoid repeating validation work both when an entire PP remains unchanged and when only some of its objects have changed. This approach is particularly useful when repository updates affect only a small portion of a PP. Its effectiveness depends on how frequently PP-level or object-level reuse conditions are satisfied and on the cost of maintaining and checking the associated cached state.¶

7.1. Correctness Target

For the same repository snapshot, trust anchor set, validation policy, validation time, and applicable RPKI validation rules, incremental validation is expected to produce the same validated payload output as full validation. This equivalence is the primary correctness objective of incremental validation, regardless of the cache and reuse strategies used.¶

7.2. Uncertain or Inconsistent Cache State

If cached validation state is missing, inconsistent with the current repository data, or insufficient to determine whether a previous result remains applicable, the RP should not reuse the affected result. The RP should revalidate the affected objects and their dependent validation state, or perform full validation of the affected PP when necessary. A partial or failed validation result should not replace a previously successful cache entry as though the current validation had completed successfully.¶

7.3. Fallback

If the current repository data for a PP cannot be used, for example, because its manifest or CRL is invalid or the repository data is inconsistent with the manifest, an RP may fall back, according to local policy, to the last successfully validated version of that PP. If the cached validation state for that version still satisfies the PP-level reuse conditions, the RP may reuse the cached result, subject to checks required by the current validation time. Otherwise, the RP needs to validate the previous PP data under the current validation context before using its results.¶