Internet-Draft RPKI RP Incremental Validation July 2026
Su, et al. Expires 7 January 2027 [Page]
Workgroup:
SIDROPS
Internet-Draft:
draft-su-sidrops-rpki-rp-incremental-validation-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
Y. Su
Zhongguancun Laboratory
L. Qin
Zhongguancun Laboratory
D. Li
Tsinghua University

A Publication-Point-Based Incremental Validation Procedure for RPKI Relying Parties

Abstract

RPKI Relying Parties commonly perform top-down validation of the RPKI certificate tree after repository synchronization. Existing repository synchronization mechanisms can update the local repository incrementally, avoiding a complete retrieval of all repository data. However, after such an incremental repository update, an RP implementation may still repeat full top-down validation over the local repository. It means that the RP starts from the trust anchors and performs complete validation checks for all currently reachable RPKI objects encountered during the traversal. Repeating such validation for objects whose validation inputs have not changed can introduce unnecessary validation overhead.

This document specifies a publication-point-based incremental validation procedure for RPKI RPs. The procedure is intended to reduce redundant validation work after incremental repository synchronization, while preserving the same validation result as a full top-down validation over the same repository snapshot, trust anchor set, validation policy, and validation time. This document does not change the syntax or validation semantics of any RPKI object.

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

▲

Table of Contents

1. Introduction

RPKI RPs validate RPKI data by traversing the certificate tree from trust anchors to subordinate CAs and payload-carrying signed objects, such as ROAs and ASPA. This top-down validation model ensures that each object is evaluated in the context of its issuing CA, the applicable manifest, the applicable CRL, the applicable effective resource context, and the current validation time. However, repeating full top-down validation after every repository synchronization cycle can introduce significant validation overhead, even when only a small portion of the publication point has changed.

This document specifies a publication-point-based incremental validation procedure. The procedure uses cached validation state associated with CA publication points, together with the current manifest and CRL, to determine which validation results can be safely reused and which checks must be re-executed. The RP still traverses the currently reachable RPKI tree from the trust anchors. The difference is that unchanged objects do not necessarily require repeated parsing, signature verification, and full object validation during every validation cycle.

This document specifies an optional procedure for reducing redundant validation work inside an RP implementation. This document does not define a new RPKI object format, does not change RRDP or rsync behavior, and does not modify the validation semantics of RPKI certificates, manifests, CRLs, ROAs, ASPA objects, or other RPKI signed objects. The cache structures and identifiers described in this document are conceptual; implementations may use equivalent internal representations. The intended correctness property is that, for the same repository snapshot, trust anchor set, validation policy, and validation time, the incremental validation procedure produces the same validated payload output as a full top-down validation.

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

3. Cache State and Bootstrapping

Incremental validation depends on validation state produced by a previous validation cycle. When no usable cache exists, the RP first obtains a complete local repository snapshot using its selected synchronization mechanism, and then performs full top-down validation from the trust anchors. During this initial validation, the RP validates the currently reachable CA publication points, including the manifest, CRL, and all objects referenced by each valid manifest. The validation results produced during this process are used to build the initial cache state.

The cache can be represented as a mapping from a CA identifier to the validation state of the publication point associated with that CA:

ValidationCache = {
    CA_ID -> PublicationPointState
}

A cache entry is created only for a CA that has been validated successfully in a previous validation cycle and whose publication point has a valid manifest and a valid CRL. A CA_ID identifies the validated CA certificate object and the publication point associated with that CA. The representation is:

CA_ID = (CA_certificate_URI, hash(CA_certificate_object))

A publication point cache entry contains the state needed to determine whether the publication point, or individual objects in that publication point, can be reused in a later validation cycle:

PublicationPointState = {

    ca_effective_resources,

    manifest: {
        uri,
        hash,
        thisUpdate,
        nextUpdate,
    },

    crl: {
        uri,
        hash,
        thisUpdate,
        nextUpdate,
    },

    objects: {
        (filename, file_hash) -> ObjectValidationState
    }
}

For the publication point, ca_effective_resources records the effective IP address and AS number resources of the CA certificate under which the publication point was validated. For the manifest, thisUpdate and nextUpdate refer to the time fields in the manifest eContent. For the CRL, thisUpdate and nextUpdate refer to the CRL validity interval.

The per-object validation state records the information needed to decide whether a previous validation result can be reused in a later validation cycle:

ObjectValidationState = {
    uri,
    filename,
    hash,
    object_type,
    validation_status,
    failure_reason,
    cert_serial,
    notBefore,
    notAfter,
    effective_resources,
    derived_payload
}

The cert_serial, notBefore, and notAfter fields record the serial number and validity interval of the CA certificate or the EE certificate associated with the signed object. The effective_resources field is relevant only for valid subordinate CA certificates and records the subordinate CA's current effective resources. The derived_payload field is relevant only for valid payload-carrying signed objects. For example, derived_payload records the effective validated payload generated by ROA and ASPA objects.

The failure_reason field is relevant only for objects that were invalid in the cached state. This field requires distinguishing at least failures caused by the validation time being earlier than the relevant notBefore time and failures caused by CRL revocation. Such objects can become valid in a later validation cycle if the current validation time has entered the relevant validity interval, or if the current CRL no longer revokes the relevant certificate serial number.

4. Incremental Validation Procedure

After the RP has obtained an updated local repository snapshot, validation starts from the configured trust anchors and proceeds top-down. In this document, the recursive validation process is modeled as repeated execution of ValidatePP(CA) for each currently valid CA encountered during the traversal.

For each accepted trust anchor or validated subordinate CA, the RP computes the corresponding CA_ID. If no usable cache entry exists for the CA_ID, the publication point is processed as a new CA publication point as described in Section 4.2. If a usable cache entry exists, the publication point is processed as an existing CA publication point as described in Section 4.3.

4.1. Trust Anchor Processing

The RP starts validation from its configured trust anchors. Trust anchor processing follows the applicable TAL processing rules [RFC8630] and the RP's local trust anchor configuration.

After a trust anchor has been accepted in the current validation cycle, it is treated as a special self-signed root CA for the purpose of its publication point processing. The RP computes the corresponding CA_ID for the accepted trust anchor certificate. If a usable cache entry exists for this CA_ID, the trust anchor publication point is processed as an existing CA publication point as described in Section 4.3. Otherwise, it is processed as a new CA publication point as described in Section 4.2.

If a trust anchor is not accepted in the current validation cycle, its subtree does not contribute to the current validated payload output.

4.2. New CA Publication Point

A CA publication point is considered new when the CA_ID of the current CA does not match any usable entry in the validation cache. For a new CA publication point, the RP performs full validation for that publication point according to the applicable RPKI specifications, including resource certificate and CRL validation [RFC6487] [RFC9829], signed object validation [RFC6488] [RFC9589], manifest validation [RFC9286], and validation of supported payload-carrying object types such as ROAs [RFC9582] and ASPA objects [I-D.ietf-sidrops-aspa-profile]. In general, the RP may:

  1. locate and validate the manifest and CRL associated with the current CA;

  2. check that the objects referenced by the manifest are present in the current local repository snapshot and match the hashes recorded in the manifest;

  3. fully validate the objects referenced by the manifest, generate validated payloads from valid payload-carrying objects, and recursively process valid subordinate CAs;

  4. record the resulting publication point state, including ca_effective_resources and per-object state, in the validation cache for later validation cycles.

This subsection does not redefine the validation rules for RPKI objects. Certificate and CRL validation, manifest processing, signed object validation, and payload extraction follow the applicable RPKI specifications for the corresponding object types.

4.3. Existing CA Publication Point

A CA publication point is considered existing when the CA_ID of the current CA matches a usable entry in the validation cache. A CA_ID cache hit indicates that the CA certificate object itself has not changed. It does not, by itself, indicate that the CA is reached under the same resource context, or that all cached validation results can be reused.

4.3.1. CA Effective Resource Context Checking

The RP first compares the current effective resources (effective_resources) of the CA certificate, as computed when validating that CA certificate in its parent publication point, with the cached ca_effective_resources of the CA's own publication point cache.

If the two values differ, the RP does not reuse the cached publication point state or cached object validation state for this CA publication point. The publication point is processed by full validation as described in Section 4.2 under the current ca_effective_resources.

If the two values are equal, the RP processes the current manifest and CRL as described in Section 4.3.2.

4.3.2. Manifest and CRL Processing

The RP locates the current manifest and CRL associated with the CA in the current local repository snapshot and computes their object hashes. If either the manifest or the CRL is missing, the RP may fall back to the cached publication point state according to local policy.

The RP then applies one of the following cases.

Case 1: Manifest and CRL unchanged.

If both the current manifest hash and the current CRL hash match the cached manifest hash and cached CRL hash, the RP checks the cached manifest thisUpdate and nextUpdate values and the cached CRL thisUpdate and nextUpdate values against the current validation time.

If these checks succeed, the RP processes the publication point as described in Section 4.3.3. If either the cached manifest or the cached CRL is not valid at the current validation time, the publication point is considered invalid for the current validation cycle.

Case 2: Manifest changed.

If the current manifest hash differs from the cached manifest hash, the RP validates the current manifest and current CRL according to the applicable RPKI validation rules. The current CRL must be referenced by the current manifest and must match the hash recorded in the current manifest.

If validation succeeds, the RP uses the object set defined by the current manifest and processes the publication point as described in Section 4.3.4. If the manifest or CRL validation fails, the RP may fall back to the cached publication point state according to local policy.

4.3.3. Publication-Point-Level Reuse

Publication-point-level reuse is used when the CA_ID, ca_effective_resources, manifest hash, and CRL hash all match the cached state.

In this case, the RP reuses the cached validation state for the publication point, subject only to checks that depend on the current validation time.

  1. For each cached object that was valid in the cached state, the RP checks whether the relevant certificate or signed object is valid at the current validation time.

  2. For each cached object that was invalid only because the validation time was earlier than the relevant notBefore time, the RP checks whether the relevant certificate or signed object is within its validity interval at the current validation time. If it is, the RP fully validates the object before treating it as valid in the current validation cycle.

  3. If an object is valid in the current validation cycle and is a payload-carrying signed object, its derived_payload contributes to the current validated payload output.

  4. If an object is valid in the current validation cycle and is a subordinate CA certificate, the RP recursively applies ValidatePP(child CA) using the subordinate CA's effective_resources.

Cached objects that are not valid in the current validation cycle do not contribute to the current validated payload output.

4.3.4. Object-Level Reuse

Object-level reuse is used when the CA_ID and ca_effective_resources match the cached state, but the current manifest hash differs from the cached manifest hash.

The current manifest defines the object set of the current publication point. Objects that are not referenced by the current manifest do not contribute to the current validated payload output.

  1. For every object referenced by the current manifest, the RP checks that the corresponding raw object exists in the current local repository snapshot and that the object hash matches the hash recorded in the current manifest. If any referenced object is missing or has a mismatching hash, the RP may fall back to the cached publication point state according to local policy.

  2. For each object referenced by the current manifest, the RP looks for cached object validation state using the object's filename and hash.

  3. If matching cached object validation state exists and the object was valid in the cached state, the RP checks whether the relevant certificate or signed object is valid at the current validation time. If the current CRL hash differs from the cached CRL hash, the RP also checks whether the relevant certificate serial number is revoked by the current CRL. If these checks succeed, the cached object validation result is reused.

  4. If matching cached object validation state exists and the object was invalid in the cached state, the RP uses the recorded failure_reason to decide whether the object needs to be validated again. The RP fully validates the object again only when one of the following conditions is met:

    • the previous failure was caused by the validation time being earlier than the relevant notBefore time, and the relevant certificate or signed object is within its validity interval at the current validation time; or

    • the previous failure was caused by CRL revocation, the current CRL hash differs from the cached CRL hash, and the current CRL no longer contains the relevant certificate serial number.

    If neither condition is met, the object remains invalid in the current validation cycle.

  5. If no matching cached object validation state exists, the RP fully validates the object according to the applicable RPKI validation rules.

  6. For each object that is valid in the current validation cycle, the RP processes the object according to its type. If the object is a payload-carrying signed object, its derived payload contributes to the current validated payload output. If the object is a subordinate CA certificate, the RP recursively applies ValidatePP(child CA) using the subordinate CA's current effective_resources.

Objects that are not valid in the current validation cycle do not contribute to the current validated payload output.

4.3.5. Updating the Publication Point Cache

After the existing CA publication point has been processed successfully for the current validation cycle, the RP updates the cache entry for the corresponding CA_ID.

The updated cache entry records the current ca_effective_resources, current manifest state, current CRL state, and the validation state of the objects in the current publication point. The previous cache entry for the same CA_ID is replaced by the newly computed publication point state.

Implementations may update the cache using any internal mechanism. To avoid using partially updated validation state in later cycles, an implementation can update the cache entry atomically after the publication point has been processed.

5. Failure Handling and Fallback

If a new CA publication point cannot be validated, no previous publication point state exists for the corresponding CA_ID. In this case, the publication point is invalid for the current validation cycle, and no valid cache entry is created for that CA_ID.

For an existing CA publication point, processing can fail if the current manifest is invalid, the current CRL is invalid, the current repository snapshot is inconsistent with the current manifest, or the publication point has to be fully validated but full validation does not succeed. In these cases, the RP may use the cached publication point state for the same CA_ID as a fallback according to local policy. This fallback represents the last successfully validated state for that CA publication point.

Fallback to cached publication point state is a local policy behavior and is outside the equivalence guarantee of this procedure. When fallback is used, the RP still applies checks that depend on the current validation time, such as validity-time checks for the cached manifest, cached CRL, and cached objects. Objects that remain valid after these checks may contribute to the current validated payload output.

An implementation should not replace a previous valid cache entry with partial or failed state. The cache entry for a CA_ID should be updated only after the publication point has been successfully processed in the current validation cycle.

6. Correctness Considerations

The correctness of this procedure relies on the following properties:

  1. Validation still proceeds top-down from the accepted trust anchors, so only currently reachable objects can contribute to the validated payload output.

  2. The CA_ID binds cached state to a specific CA certificate object. If the CA certificate changes, the cache entry is not reused and the publication point is processed as new.

  3. Publication-point-level reuse is used only when the CA_ID, ca_effective_resources, manifest hash, and CRL hash all match the cached state. Cached results are reused only after applying checks that depend on the current validation time.

  4. If the CA_ID matches but the current ca_effective_resources differ from the cached ca_effective_resources, this procedure does not reuse cached publication point state or cached object validation results from that publication point.

  5. During object-level reuse, the current manifest defines the object set of the publication point. A cached object validation result is reused only for an object that is referenced by the current manifest and has the same filename and hash as the cached object state.

  6. A cache hit does not bypass checks that may change across validation cycles. The current validation time is applied before reuse. When object-level reuse is performed with a CRL that differs from the cached CRL, the relevant certificate serial number is checked against the current CRL before reuse.

Under these conditions, the incremental procedure preserves the validation result of a complete top-down validation over the same repository snapshot, trust anchor set, validation policy, and validation time.

7. Security Considerations

This document does not change the syntax or validation semantics of any RPKI object. The main security consideration is that cached validation state MUST NOT be reused unless the cache reuse conditions specified in this document are satisfied. In particular, an RP MUST apply the current validation time, MUST apply the current CRL state when required by this procedure, and MUST confirm that the current effective resource context matches the cached state before reusing cached validation results.

Implementations should protect the integrity of the validation cache. Corruption or unauthorized modification of cached validation state could cause an RP to reuse incorrect validation results. If cache state is missing, inconsistent, or cannot be trusted, the RP should perform full validation for the affected publication point.

Fallback to cached publication point state is a local policy behavior and is outside the equivalence guarantee of this procedure.

8. IANA Considerations

This document has no IANA requests.

Acknowledgements

Normative References

[RFC8630]
Huston, G., Weiler, S., Michaelson, G., Kent, S., and T. Bruijnzeels, "Resource Public Key Infrastructure (RPKI) Trust Anchor Locator", RFC 8630, DOI 10.17487/RFC8630, , <https://www.rfc-editor.org/info/rfc8630>.
[RFC6487]
Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, DOI 10.17487/RFC6487, , <https://www.rfc-editor.org/info/rfc6487>.
[RFC9829]
Snijders, J., Maddison, B., and T. Buehler, "Handling of Resource Public Key Infrastructure (RPKI) Certificate Revocation List (CRL) Number Extensions", RFC 9829, DOI 10.17487/RFC9829, , <https://www.rfc-editor.org/info/rfc9829>.
[RFC6488]
Lepinski, M., Chi, A., and S. Kent, "Signed Object Template for the Resource Public Key Infrastructure (RPKI)", RFC 6488, DOI 10.17487/RFC6488, , <https://www.rfc-editor.org/info/rfc6488>.
[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, , <https://www.rfc-editor.org/info/rfc9589>.
[RFC9286]
Austein, R., Huston, G., Kent, S., and M. Lepinski, "Manifests for the Resource Public Key Infrastructure (RPKI)", RFC 9286, DOI 10.17487/RFC9286, , <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, , <https://www.rfc-editor.org/info/rfc9582>.
[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, , <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-27>.
[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Authors' Addresses

Yingying Su
Zhongguancun Laboratory
Beijing
China
Lancheng Qin
Zhongguancun Laboratory
Beijing
China
Dan Li
Tsinghua University
Beijing
China