RPKI Certificate Tree Validation by a Relying Party Tool

In order to use information published in RPKI repositories, Relying Parties (RP) need to retrieve and validate the content of certificates, CRLs, and other RPKI signed objects. To validate a particular object, one must ensure that all certificates in the certificate chain up to the Trust Anchor (TA) are valid. Therefore the validation of a certificate tree is usually performed top-down, starting from the TA certificate and descending down the certificate chain, validating every encountered certificate and its products. The result of this process is a list of all encountered RPKI objects with a validity status attached to each of them. These results may later be used by a Relying Party in taking routing decisions, etc. Traditionally RPKI data is made available to RPs through the repositories accessible over rsync protocol. Relying parties are advised to keep a local copy of repository data, and perform regular updates of this copy from the repository (Section 5 of ). The RPKI Repository Delta Protocol introduces another method to fetch repository data and keep the local copy up to date with the repository. This document describes how the RIPE NCC RPKI Validator discovers RPKI objects to download, builds certificate paths, and validates RPKI objects, independently from what repository access protocol is used. To achieve this, it puts downloaded RPKI objects in an object store, where objects could be found by their URI, hash of their content, value of the object's AKI field, or combination of these. It also keeps track of download and validation time for every object, to perform cleanups of the local copy.

This algorithm relies on the properties of the file hash algorithm (defined in ) to compute the hash of repository objects. It assumes that any two objects for which the hash value is the same, are identical. The hash comparison is used when matching objects in the repository with entries on the manifest, and when looking up objects in the object store ().

There are several possible ways of discovering products of a CA certificate: one could use all objects located in a repository directory designated as a publication point for a CA, or only objects mentioned on the manifest located at that publication point (see Section 6 of ), or use all objects whose AKI field matches the SKI field of a CA certificate. Since the current set of RPKI standards requires use of the manifest to describe the content of a publication point, this implementation requires a consistency between the publication point content and manifest content. Therefore it will not use in the validation process objects that are found in the publication point but do not match any of the entries of that publication point's manifest (see ). It will also issue warnings for all found mismatches, so that the responsible operators could be made aware of inconsistencies and fix them.

The validation of a Trust Anchor (TA) certificate tree starts from its TA certificate. To retrieve the TA certificate, a Trust Anchor Locator (TAL) object is used, as described in . If the TA certificate is retrieved, it is validated according to the Section 7 of and Section 2.2 of . If the TA certificate is valid, then all its subordinate objects are validated as described in . Otherwise the validation of certificate tree is aborted and an error is issued. For all repository objects that were validated during this validation run, their validation timestamp is updated in an object store (see ). Outdated objects are removed from the store as described in . This completes the validation of the TA certificate tree.

The following steps are performed in order to fetch the Trust Anchor Certificate: (Optional) If the Trust Anchor Locator contains a "prefetch.uris" field, pass the URIs contained in that field to the fetcher (see ). (This field is a non-standard extension to the TAL format. It helps fetching non-hierarchical rsync repositories more efficiently.) Extract the TA certificate URI from the TAL's URI section (see Section 2.1 of ) and pass it to the object fetcher (). Retrieve from the object store (see ) all certificate objects, for which the URI matches the URI extracted from the TAL in the previous step, and the public key matches the subjectPublicKeyInfo field of the TAL (see Section 2.1 of ). If no, or more than one such objects are found, issue an error and abort certificate tree validation process with an error. Otherwise, use the single found object as the Trust Anchor certificate.

The following steps describe the validation of a single resource certificate: If both the caRepository (Section 4.8.8.1 of ), and the id-ad-rpkiNotify (Section 3.5 of ) SIA pointers are present in the given resource certificate, use a local policy to determine which pointer to use. Extract the URI from the selected pointer and pass it to the object fetcher (see ). For a given resource certificate, find its manifest and certificate revocation list (CRL), using the procedure described in . If no such manifest and CRL could be found, stop validation of this certificate, consider it invalid, and issue an error. Compare the URI found in the given resource certificate's id-ad-rpkiManifest field (Section 4.8.8.1 of ) with the URI of the manifest found in the previous step. If they are different, issue a warning. Perform manifest entries discovery and validation as described in . Validate all resource certificate objects found on the manifest, using the CRL object found on the manifest, according to Section 7 of . Validate all ROA objects found on the manifest, using the CRL object found on the manifest, according to the Section 4 of . Validate all Ghostbusters Record objects found on the manifest, using the CRL object found on the manifest, according to the Section 7 of . For every valid resource certificate object found on the manifest, apply the procedure described in this section, recursively, provided that this resource certificate (identified by its SKI) has not yet been validated during current repository validation run.

Fetch from the store (see ) all objects of type manifest, whose certificate's AKI field matches the SKI of the current CA certificate. If no such objects are found, stop processing current resource certificate and issue an error. Find among found objects the manifest object with the highest manifestNumber field (Section 4.2.1 of ), for which all following conditions are met: There is only one entry in the manifest for which the store contains exactly one object of type CRL, whose hash matches the hash of the entry. The manifest's certificate AKI equals the above CRL's AKI. The above CRL is a valid object according to Section 6.3 of . The manifest is a valid object according to Section 4.4 of , using the CRL found above. If there is an object that matches above criteria, consider this object to be the valid manifest, and the CRL found at the previous step - the valid CRL for the current CA certificate's publication point. Report an error for every other manifest with a number higher than the number of the valid manifest.

For every entry in the manifest object: Construct an entry's URI by appending the entry name to the current CA's publication point URI. Get all objects from the store whose hash attribute equals entry's hash (see ). If no such objects are found, issue an error for this manifest entry and progress to the next entry. This case indicates that the repository does not have an object at the location listed in the manifest, or that the object's hash does not match the hash listed in the manifest. For every found object, compare its URI with the URI of the manifest entry. For every object with non-matching URI issue a warning. This case indicates that the object from the manifest entry is found at a different location in a (possibly different) repository. If no objects with matching URI found, issue a warning. This case indicates that there is no object found in the repository at the location listed in the manifest entry (but there is at least one matching object found at a different location). Use all found objects for further validation.

At the end of the TA tree validation the store cleanup is performed: Given all objects that were encountered during the current validation run, remove from the store () all objects whose URI attribute matches the URI of one of the encountered objects, but the content's hash is different. This removes from the store objects that were replaced in the repository by their newer versions at the same URIs. Remove from the store all objects that were last encountered during validation long time ago (as specified by the local policy). This removes objects that do not appear on any valid manifest anymore (but possibly still published in a repository). Remove from the store all objects that were downloaded recently (as specified by the local policy), but have never been used in a validation process. This removes objects that have never appeared on any valid manifest. Shortening the time interval used in step 2 will free disk space used by the store, to the expense of downloading removed objects again if they are still published in the repository. Extending the time interval used in step 3 will prevent repeated downloads of repository objects, with the risk that such objects, if created massively by mistake or adversely, will fill up local disk space, if they are not cleaned up promptly.

The fetcher is responsible for downloading objects from remote repositories (described in Section 3 of ) using rsync protocol (), or RPKI Repository Delta Protocol (RRDP) ().

For every successfully visited URI the fetcher keeps track of the last time it happened.

This operation receives one parameter – a URI. For rsync protocol this URI points to a directory in a remote repository. For RRDP repository it points to the repository's notification file. The fetcher performs following steps: If data associated with the URI has been downloaded recently (as specified by the local policy), skip following steps. Download the remote objects using the URI provided (for an rsync repository use a recursive mode). For every new object that is downloaded, try to parse it as an object of specific RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record), based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform basic RPKI object validation (excluding resource certification path validation), as specified in and . Put every downloaded valid object in the object store (). The time interval used in the step 1 should be chosen based on the acceptable delay in receiving repository updates.

This operation receives one parameter – a URI that points to an object in a repository. The fetcher performs following operations: If data associated with the URI has been downloaded recently (as specified by the local policy), skip all following steps. Download the remote object using the URI provided. Try to parse the downloaded object as an object of a specific RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record), based on the object's filename extension (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform basic RPKI object validation (excluding resource certification path validation), as specified in and . If the downloaded object is not valid, issue an error and skip further steps. Delete all objects from the object store () whose URI matches the URI given. Put the validated object in the object store ().

Put given object in the store, along with its type, URI, hash, and AKI, if there is no record with the same hash and URI fields.

Retrieve all objects from the store whose hash attribute matches the given hash.

Retrieve from the store all objects of type certificate, whose URI attribute matches the given URI.

Retrieve from the store all objects of type manifest, whose AKI attribute matches the given AKI.

For a given URI, delete all objects in the store with matching URI attribute.

For a given URI and a list of hashes, delete all objects in the store with matching URI, whose hash attribute is not in the given list of hashes.

For all objects in the store whose hash attribute matches the given hash, set the last validation time attribute to the given timestamp.

This document describes the algorithm as it is implemented by the software development team at the RIPE NCC. The authors would also like to acknowledge contributions by Carlos Martinez, Andy Newton, and Rob Austein.

This document has no actions for IANA.

This implementation will not detect possible hash collisions in the hashes of repository objects (calculated using the file hash algorithm specified in ), and considers objects with same hash values as identical. This algorithm uses the content of a manifest object to discover other objects issued by a specified CA. It verifies that the manifest is located in the publication point designated in the CA Certificate. However, if there are other (not listed in the manifest) objects located in that publication point directory, they will be ignored, even if their content is correct and they are issued by the same CA as the manifest. In contrast, objects whose content hash matches the hash listed in the manifest, but that are not located in the publication directory listed in their CA certificate, will be used in the validation process (although a warning will be issued in that case). The store cleanup procedure described in tries to minimise removal and subsequent re-fetch of objects that are published in a repository but not used in the validation. Once such objects are removed from the remote repository, they will be discarded from the local object store after a period of time specified by a local policy. By generating an excessive amount of syntactically valid RPKI objects, a man-in-the-middle attack between a validating tool and a repository could force an implementation to fetch and store those objects in the object store before they are validated and discarded, leading to an out-of-memory or out-of-disk-space conditions, and, subsequently, a denial of service.