RPKI validation using a local cache

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

It has been suggested by various people that in order to mitigate availability issues in the RPKI repositories, it would be good to support alternative fetch algorithms (easier to maintain by publication servers), multiplepublication points (use multiple publication servers) and sharing of unvalidated objects between validating caches (less dependence on a central publication server). All these approaches share in common that unvalidated RPKI objects can potentially be retrieved in a number of different ways, separate from the actual validation process. And all these approaches face the same challenge: how to perform a top-down validation process if the SIA, AIA and CRLDP pointers don’t necessarily point to the locations where the Relying Party retrieved the objects. In this document we propose a validation algorithm that does not rely on these pointers. In particular we will be using a local object cache that allows SKI and AKI fields in certificates and SHA-256 hashes of objects to be used to perform top-down validation.

There is more than one way to do this, and to keep the focus of this document clear we will not go into details on this here. However, a separate informational document on this subject will be provided as a reference to implementers. For the remainder of this document we will assume that we have access to a local cache that satisfies the requirements documented below.

The local cache MUST support object retrieval by SHA-256 hash. The local cache MUST support manifest retrieval by the AKI of the manifest EE certificate. The local cache MUST pro-actively retrieve objects for the publication points known to it. The local cache MUST support some mechanisms to communicate these publication points. E.g. by requiring the Relying Party to supply the CA certificate for which objects are being sought so that the SIA field can be used to (de-)register publication points. In case of cache misses (no manifest or object by that hash found) the local cache SHOULD attempt re-fetching objects.

We validate a trust anchor certificate and note the SKI. Then we search for the most recent manifest in our cache that has an AKI that matches this SKI and has a valid signature. We expect that this MFT contains one CRL entry that we will use to check for revocations. We will retrieve all objects mentioned on the manifest from our cache, by using their hash as a key. We then validate all objects as described in the current standards, with some minor caveats detailed below. We will then recursively find manifests, crls and validate signed objects for any certificate we validated this way.

The validation process starts with downloading and validating a the Trust Anchor certificate as described in RFC6490. The validated certificate we obtain this way will be used as the first validated certificate in the recursive algorithm outlined below.

A validated CA certificate has a unique SKI that we can use to identify it. This SKI will be used as the AKI in any certificates signed by this CA certificate and the CRL it publishes.

We retrieve the manifest with the most recent “this update time” that has an EE certificate with an AKI that matches the SKI of the CA certificate we are processing. The RP MUST validate that the manifest lists exactly one CRL and that this CRL can be retrieved from the cache as described in the next section. This manifest is then validated using the same criteria as described in RFC6486 section 4.4. With the exception that: The CRLDP is ignored and the CRL retrieved above is used The SIA and AIA fields are not used for validation Furthermore if all manifests found this way have invalid signatures then the Relying Party MUST conclude that the SKI on the CA certificate was faked and the CA does not hold the private key, and therefore MUST reject this CA certificate. Note that this situation is extremely unlikely to arise by accident as the normal Certificate Sign Request as described in RFC6492 includes proof of possession of the private key by the certificate requester to the issuing CA.

The manifest MUST list only one CRL that can be retrieved from the local cache by it SHA-256 hash. This CRL MUST pass all validation checks described in RFC5280. This CRL MUST not revoke the EE certificate of the manifest. If no such CRL can be found then the Relying Party MUST fall back to the next most recent manifest in the previous step.

All other objects listed on the manifest can be retrieved from the cache by the SHA-256 hash. They are each validated according to the validation rules stipulated for their object type, which we can deduce from the extension in the name, with the exception that: The CRLDP is ignored and the CRL retrieved above is used The SIA and AIA fields are not used for validation Because Prefix Origin Validation (RFC Editor queue) needs to loop over *all* the relevant Validated ROA Prefixes to determine Route validity it is RECOMMENDED that Relying Parties first check that all objects listed on the manifest can be retrieved from the cache, and if any objects are missing fall back to the next most recent manifest for processing. If this would result in rejecting a publication point altogether, e.g. because the previous manifest EE certificate has expired, then it’s RECOMMENDED that the latest manifest is used despite the missing objects. All these conditions MUST result in warnings to the users of Relying Party software.

Any valid CA certificates found in the previous step can now be processed recursively starting at step 4.3.

This is all in line with the Resource Certificate Repository Structure as described in RFC6481. However, it could be useful to add the following normative wording to section 2.2: “A CA's publication repository MUST contain the current (non-expired and non-revoked) certificates issued by this CA, the most recent CRL issued by this CA, the current manifest, and all other current signed objects that can be verified using an EE certificate [RFC6487] issued by this CA. A CA MUST list all objects that it desires to be considered for top-down validation on a single manifest, and it MUST NOT divide this list of products over multiple manifests. A CA MUST publish all the objects listed on this manifest. A CA MAY sign other objects that are not intended for publication in the RPKI repository. Such objects MUST NOT appear on the manifest and SHOULD not be published in the repository”

Section 1 of RFC6486 has the following on the main purpose of manifests in the RPKI: "A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point." RFC6486 was written in the context of an rpki repository that assumes single publication points for CAs that can support recursive fetching of all published objects over rsync. Because RPs can get all objects that a CA publishes this way there was no need for any object that lists these objects explicitly for retrieval purposes, and therefore the manifest was not thought to carry this responsibility. Having said that, however, there are a number use cases that warrant that manifests MUST be useful in this way: The validation process described in this document is independent of the location where objects are retrieved. Manifests are used to determine which objects are currently published by a CA. BGP Prefix Origin Validation (RFC editor queue) section 2 describes a process for determining route validity that loops over all Validated Roa Prefixes. Therefore it is very desirable to have an authoritative source of information that instructs the RP which objects MUST be validated. Other transport protocols, such as http, may be added in the future. These protocols do not necessarily support recursive fetching and therefore they need an authoritative list to determine what to fetch. For this reason we propose to change the standards so that manifests MAY be used as the authoritative list of objects that a CA desires to publish. In the next sections we describe the implications this has on the use of manifests by RPs as currently described in section 6 of RFC6486.

A missing manifest may be the result of an error by the CA or the publisher. It is most strongly RECOMMENDED that CAs and publishers monitor this and fix the situation should problems arise. If no current manifest can be found by the Relying Party then they SHOULD use the most recent old manifest in their possession, as described in section 4.4 in this document.

Relying Parties that find that objects listed on the manifest are missing MAY decide to use the most recent manifest in their possession for which all objects could be found, as described in section 4.6 in this document. As described in RFC6481 CAs MUST publish all objects that MUST be considered for top-down validation, and they SHOULD NOT publish any other objects. Therefore Relying Parties MAY ignore any objects found in a repository that are not listed on a manifest.

Relying Parties MUST reject current published objects with hash values not matching the validated current manifest.

TBD