doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc8488.txt b/doc/rfc/rfc8488.txt
new file mode 100644
index 0000000..424b780
--- /dev/null
+++ b/doc/rfc/rfc8488.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      O. Muravskiy
+Request for Comments: 8488                                      RIPE NCC
+Category: Informational                                   T. Bruijnzeels
+ISSN: 2070-1721                                               NLnet Labs
+                                                           December 2018
+
+
+ RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI)
+                      Certificate Tree Validation
+
+Abstract
+
+   This document describes an approach to validating the content of the
+   Resource Public Key Infrastructure (RPKI) certificate tree, as it is
+   implemented in the RIPE NCC RPKI Validator.  This approach is
+   independent of a particular object retrieval mechanism, which allows
+   it to be used with repositories available over the rsync protocol,
+   the RPKI Repository Delta Protocol (RRDP), and repositories that use
+   a mix of both.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8488.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 1]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+Copyright Notice
+
+   Copyright (c) 2018 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 2]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
+   2.  General Considerations  . . . . . . . . . . . . . . . . . . .   4
+     2.1.  Hash Comparisons  . . . . . . . . . . . . . . . . . . . .   4
+     2.2.  Discovery of RPKI Objects Issued by a CA  . . . . . . . .   5
+     2.3.  Manifest Entries versus Repository Content  . . . . . . .   5
+   3.  Top-Down Validation of a Single Trust Anchor Certificate Tree   6
+     3.1.  Fetching the Trust Anchor Certificate Using the Trust
+           Anchor Locator  . . . . . . . . . . . . . . . . . . . . .   6
+     3.2.  CA Certificate Validation . . . . . . . . . . . . . . . .   7
+       3.2.1.  Finding the Most Recent Valid Manifest and CRL  . . .   8
+       3.2.2.  Validating Manifest Entries . . . . . . . . . . . . .   9
+     3.3.  Object Store Cleanup  . . . . . . . . . . . . . . . . . .  10
+   4.  Remote Objects Fetcher  . . . . . . . . . . . . . . . . . . .  11
+     4.1.  Fetcher Operations  . . . . . . . . . . . . . . . . . . .  11
+       4.1.1.  Fetch Repository Objects  . . . . . . . . . . . . . .  12
+       4.1.2.  Fetch Single Repository Object  . . . . . . . . . . .  12
+   5.  Local Object Store  . . . . . . . . . . . . . . . . . . . . .  12
+     5.1.  Store Operations  . . . . . . . . . . . . . . . . . . . .  12
+       5.1.1.  Store Repository Object . . . . . . . . . . . . . . .  12
+       5.1.2.  Get Objects by Hash . . . . . . . . . . . . . . . . .  12
+       5.1.3.  Get Certificate Objects by URI  . . . . . . . . . . .  13
+       5.1.4.  Get Manifest Objects by AKI . . . . . . . . . . . . .  13
+       5.1.5.  Delete Objects for a URI  . . . . . . . . . . . . . .  13
+       5.1.6.  Delete Outdated Objects . . . . . . . . . . . . . . .  13
+       5.1.7.  Update Object's Validation Time . . . . . . . . . . .  13
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
+     7.1.  Hash Collisions . . . . . . . . . . . . . . . . . . . . .  13
+     7.2.  Algorithm Agility . . . . . . . . . . . . . . . . . . . .  13
+     7.3.  Mismatch between the Expected and Actual Location of an
+           Object in the Repository  . . . . . . . . . . . . . . . .  14
+     7.4.  Manifest Content versus Publication Point Content . . . .  14
+     7.5.  Possible Denial of Service  . . . . . . . . . . . . . . .  15
+   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
+     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  15
+     8.2.  Informative References  . . . . . . . . . . . . . . . . .  16
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17
+
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 3]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+1.  Introduction
+
+   This document describes how the RIPE NCC RPKI Validator version 2.25
+   has been implemented.  Source code for this software can be found at
+   [rpki-validator].  The purpose of this document is to provide
+   transparency to users of (and contributors to) this software tool.
+
+   In order to use information published in RPKI repositories, Relying
+   Parties (RPs) need to retrieve and validate the content of
+   certificates, Certificate Revocation Lists (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
+   performed top-down, starting from the TA certificate and descending
+   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 an RP in making routing
+   decisions, etc.
+
+   Traditionally, RPKI data is made available to RPs through the
+   repositories [RFC6481] accessible over the rsync protocol [rsync].
+   RPs are advised to keep a local copy of repository data and perform
+   regular updates of this copy from the repository (see Section 5 of
+   [RFC6481]).  The RRDP [RFC8182] 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 of what repository access protocol is
+   used.  To achieve this, it puts downloaded RPKI objects in an object
+   store, where each RPKI object can be found by its URI, the hash of
+   its content, the value of its Authority Key Identifier (AKI)
+   extension, or a combination of these.  It also keeps track of the
+   download and validation time for every object, to decide which
+   locally stored objects are not used in the RPKI tree validation and
+   could be removed.
+
+2.  General Considerations
+
+2.1.  Hash Comparisons
+
+   This algorithm relies on the collision resistance properties of the
+   hash algorithm (defined in [RFC7935]) to compute the hash of
+   repository objects.  It assumes that any two objects for which the
+   hash value is the same are identical.
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 4]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+   The hash comparison is used when matching objects in the repository
+   with entries on the manifest (Section 3.2.2) and when looking up
+   objects in the object store (Section 5).
+
+2.2.  Discovery of RPKI Objects Issued by a CA
+
+   There are several possible ways of discovering potential products of
+   a Certification Authority (CA) certificate: one could 1) use all
+   objects located in a repository directory designated as a publication
+   point for a CA, 2) only use objects mentioned on the manifest located
+   at that publication point (see Section 6 of [RFC6486]), or 3) use all
+   known repository objects whose AKI extension matches the Subject Key
+   Identifier (SKI) extension (Section 4.2.1 of [RFC5280]) of a CA
+   certificate.
+
+   For publication points whose content is consistent with the manifest
+   and issuing certificate, all of these approaches should produce the
+   same result.  For inconsistent publication points, the results might
+   be different.  Section 6 of [RFC6486] leaves the decision on how to
+   deal with inconsistencies to a local policy.
+
+   The implementation described here does not rely on content of
+   repository directories but uses the Authority Key Identifier (AKI)
+   extension of a manifest and a CRL to find in an object store
+   (Section 5) a manifest and a CRL issued by a particular CA (see
+   Section 3.2.1).  It further uses the hashes of the manifest's
+   fileList entries (Section 4.2.1 of [RFC6486]) to find other objects
+   issued by the CA, as described in Section 3.2.2.
+
+2.3.  Manifest Entries versus Repository Content
+
+   Since the current set of RPKI standards (see [RFC6481], [RFC6486],
+   and [RFC6487]) requires use of the manifest [RFC6486] to describe the
+   content of a publication point, this implementation requires strict
+   consistency between the publication point content and manifest
+   content.  (This is a more stringent requirement than established in
+   [RFC6486].)  Therefore, it will not process objects that are found in
+   the publication point but do not match any of the entries of that
+   publication point's manifest (see Section 3.2.2).  It will also issue
+   warnings for all found mismatches, so that the responsible operators
+   could be made aware of inconsistencies and fix them.
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 5]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+3.  Top-Down Validation of a Single Trust Anchor Certificate Tree
+
+   When several Trust Anchors are configured, validation of their
+   corresponding certificate trees is performed concurrently and
+   independently from each other.  For every configured Trust Anchor,
+   the following steps are performed:
+
+   1.  The validation of a TA certificate tree starts from its TA
+       certificate.  To retrieve the TA certificate, a Trust Anchor
+       Locator (TAL) object is used, as described in Section 3.1.
+
+   2.  If the TA certificate is retrieved, it is validated according to
+       Section 7 of [RFC6487] and Section 2.2 of [RFC7730].  Otherwise,
+       the validation of the certificate tree is aborted and an error is
+       issued.
+
+   3.  If the TA certificate is valid, then all its subordinate objects
+       are validated as described in Section 3.2.  Otherwise, the
+       validation of the certificate tree is aborted and an error is
+       issued.
+
+   4.  For each repository object that was validated during this
+       validation run, the validation timestamp is updated in the object
+       store (see Section 5.1.7).
+
+   5.  Outdated objects are removed from the store as described in
+       Section 3.3.  This completes the validation of the TA certificate
+       tree.
+
+3.1.  Fetching the Trust Anchor Certificate Using the Trust Anchor
+      Locator
+
+   The following steps are performed in order to fetch a Trust Anchor
+   certificate:
+
+   1.  (Optional) If the TAL contains a prefetch.uris field, pass the
+       URIs contained in that field to the fetcher (see Section 4.1.1).
+       (This field is a non-standard addition to the TAL format.  It
+       helps with fetching non-hierarchical rsync repositories more
+       efficiently.)
+
+   2.  Extract the first TA certificate URI from the TAL's URI section
+       (see Section 2.1 of [RFC7730]) and pass it to the object fetcher
+       (Section 4.1.2).  If the fetcher returns an error, repeat this
+       step for every URI in the URI section until no error is
+       encountered or no more URIs are left.
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 6]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+   3.  From the object store (see Section 5.1.3), retrieve 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 extension of the TAL (see Section 2.1 of
+       [RFC7730]).
+
+   4.  If no such objects are found or if more than one such objects are
+       found, issue an error and abort the certificate tree validation
+       process with an error.  Otherwise, use the single found object as
+       the TA certificate.
+
+3.2.  CA Certificate Validation
+
+   The following steps describe the validation of a single CA resource
+   certificate:
+
+   1.  If both the caRepository (Section 4.8.8.1 of [RFC6487]) and the
+       id-ad-rpkiNotify (Section 3.2 of [RFC8182]) instances of an
+       accessMethod are present in the Subject Information Access
+       extension of the CA 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 (that will then fetch all
+       objects available from that repository; see Section 4.1.1).
+
+   2.  For the CA certificate, find the current manifest and certificate
+       revocation list (CRL) using the procedure described in
+       Section 3.2.1.  If no such manifest and CRL could be found, stop
+       validation of this certificate, consider it invalid, and issue an
+       error.
+
+   3.  Compare the URI found in the id-ad-rpkiManifest field
+       (Section 4.8.8.1 of [RFC6487]) of the SIA extension of the
+       certificate with the URI of the manifest found in the previous
+       step.  If they are different, issue a warning but continue the
+       validation process using the manifest found in the previous step.
+       (This warning indicates that there is a mismatch between the
+       expected and the actual location of an object in a repository.
+       See Section 7.3 for the explanation of this mismatch and the
+       decision made.)
+
+   4.  Perform discovery and validation of manifest entries as described
+       in Section 3.2.2.
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 7]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+   5.  Validate all resource certificate objects found on the manifest
+       using the CRL object:
+
+       *  If the strict validation option is enabled by the operator,
+          the validation is performed according to Section 7 of
+          [RFC6487].
+
+       *  Otherwise, the validation is performed according to Section 7
+          of [RFC6487] but with the exception of the resource
+          certification path validation, which is performed according to
+          Section 4.2.4.4 of [RFC8360].
+
+       (Note that this implementation uses the operator configuration to
+       decide which algorithm to use for path validation.  It applies
+       the selected algorithm to all resource certificates, rather than
+       applying an appropriate algorithm per resource certificate based
+       on the object identifier (OID) for the Certificate Policy found
+       in that certificate, as specified in [RFC8360].)
+
+   6.  Validate all Route Origin Authorization (ROA) objects found on
+       the manifest using the CRL object found on the manifest,
+       according to Section 4 of [RFC6482].
+
+   7.  Validate all Ghostbusters Record objects found on the manifest
+       using the CRL object found on the manifest, according to
+       Section 7 of [RFC6493].
+
+   8.  For every valid CA certificate object found on the manifest,
+       apply the procedure described in this section, recursively,
+       provided that this CA certificate (identified by its SKI) has not
+       yet been validated during current tree validation run.
+
+3.2.1.  Finding the Most Recent Valid Manifest and CRL
+
+   To find the most recent issued manifest and CRL objects of a
+   particular CA certificate, the following steps are performed:
+
+   1.  From the store (see Section 5.1.4), fetch all objects of type
+       manifest whose certificate's AKI extension matches the SKI of the
+       current CA certificate.  If no such objects are found, stop
+       processing the current CA certificate and issue an error.
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 8]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+   2.  Among found objects, find the manifest object with the highest
+       manifestNumber field (Section 4.2.1 of [RFC6486]) 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, the hash of which
+          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
+          [RFC5280].
+
+       *  The manifest is a valid object according to Section 4.4 of
+          [RFC6486], and its EE certificate is not in the CRL found
+          above.
+
+   3.  If there is an object that matches the above criteria, consider
+       this object to be the valid manifest, and consider the CRL found
+       at the previous step to be the valid CRL for the current CA
+       certificate's publication point.
+
+   4.  Report an error for every other manifest with a number higher
+       than the number of the valid manifest.
+
+3.2.2.  Validating Manifest Entries
+
+   For every entry in the manifest object:
+
+   1.  Construct an entry's URI by appending the entry name to the
+       current CA's publication point URI.
+
+   2.  Get all objects from the store whose hash attribute equals the
+       entry's hash (see Section 5.1.2).
+
+   3.  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.
+
+   4.  For every found object, compare its URI with the URI of the
+       manifest entry.
+
+       *  For every object with a non-matching URI, issue a warning.
+          This case indicates that the object from the manifest entry is
+          (also) found at a different location in a (possibly different)
+          repository.
+
+
+
+Muravskiy & Bruijnzeels       Informational                     [Page 9]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+       *  If no objects with a matching URI are 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).
+
+   5.  Use all found objects for further validation as per Section 3.2.
+
+   Please note that the above steps will not reject objects whose hash
+   matches the hash listed in the manifest but whose URI does not.  See
+   Section 7.3 for additional information.
+
+3.3.  Object Store Cleanup
+
+   At the end of every TA tree validation, some objects are removed from
+   the store using the following rules:
+
+   1.  Given all objects that were encountered during the current
+       validation run, remove from the store (Section 5.1.6) all objects
+       whose URI attribute matches the URI of one of the encountered
+       objects but whose content's hash does not match the hash of any
+       of the encountered objects.  This removes from the store objects
+       that were replaced in the repository by their newer versions with
+       the same URIs.
+
+   2.  Remove from the store all objects that were last encountered
+       during validation a long time ago (as specified by the local
+       policy).  This removes objects that do not appear on any valid
+       manifest anymore (but possibly are still published in a
+       repository).
+
+   3.  Remove from the store all objects that were downloaded recently
+       (as specified by the local policy) but that have never been used
+       in the validation process.  This removes objects that have never
+       appeared on any valid manifest.
+
+   Shortening the time interval used in step 2 will free more disk space
+   used by the store, at 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 unused repository objects.  However, it will also extend
+   the interval at which unused objects are removed.  This creates a
+   risk that such objects will fill up all available disk space if a
+   large enough amount of such objects is published in the repository
+   (either by mistake or with a malicious intent).
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 10]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+4.  Remote Objects Fetcher
+
+   The fetcher is responsible for downloading objects from remote
+   repositories (described in Section 3 of [RFC6481]) using the rsync
+   protocol [rsync] or RRDP [RFC8182].
+
+4.1.  Fetcher Operations
+
+   For every visited URI, the fetcher keeps track of the last time a
+   successful fetch occurred.
+
+4.1.1.  Fetch Repository Objects
+
+   This operation receives one parameter -- a URI.  For an rsync
+   repository, this URI points to a directory.  For an RRDP repository,
+   it points to the repository's notification file.
+
+   The fetcher follows these steps:
+
+   1.  If data associated with the URI has been downloaded recently (as
+       specified by the local policy), skip the following steps.
+
+   2.  Download remote objects using the URI provided (for an rsync
+       repository, use recursive mode).  If the URI contains the "https"
+       schema and download has failed, issue a warning, replace the
+       "https" schema in the URI with "http", and try to download
+       objects again using the resulting URI.
+
+   3.  If remote objects cannot be downloaded, issue an error and skip
+       the following steps.
+
+   4.  Perform syntactic verification of fetched objects.  The type of
+       every object (certificate, manifest, CRL, ROA, or Ghostbusters
+       Record) is determined based on the object's filename extension
+       (.cer, .mft, .crl, .roa, and .gbr, respectively).  The syntax of
+       the object is described in Section 4 of [RFC6487] for resource
+       certificates, step 1 of Section 3 of [RFC6488] for signed
+       objects, Section 4 of [RFC6486] for manifests, [RFC5280] for
+       CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493]
+       for Ghostbusters Records.
+
+   5.  Put every downloaded and syntactically correct object in the
+       object store (Section 5.1.1).
+
+   The time interval used in step 1 should be chosen based on the
+   acceptable delay in receiving repository updates.
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 11]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+4.1.2.  Fetch Single Repository Object
+
+   This operation receives one parameter -- a URI that points to an
+   object in a repository.
+
+   The fetcher follows these steps:
+
+   1.  Download a remote object using the URI provided.  If the URI
+       contains the "https" schema and download failed, issue a warning,
+       replace the "https" schema in the URI with "http", and try to
+       download the object using the resulting URI.
+
+   2.  If the remote object cannot be downloaded, issue an error and
+       skip the following steps.
+
+   3.  Perform syntactic verification of the fetched object.  The type
+       of object (certificate, manifest, CRL, ROA, or Ghostbusters
+       Record) is determined based on the object's filename extension
+       (.cer, .mft, .crl, .roa, and .gbr, respectively).  The syntax of
+       the object is described in Section 4 of [RFC6487] for resource
+       certificates, step 1 of Section 3 of [RFC6488] for signed
+       objects, Section 4 of [RFC6486] for manifests, [RFC5280] for
+       CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493]
+       for Ghostbusters Records.
+
+   4.  If the downloaded object is not syntactically correct, issue an
+       error and skip further steps.
+
+   5.  Delete all objects from the object store (Section 5.1.5) whose
+       URI matches the URI given.
+
+   6.  Put the downloaded object in the object store (Section 5.1.1).
+
+5.  Local Object Store
+
+5.1.  Store Operations
+
+5.1.1.  Store Repository Object
+
+   Put the given object in the store if there is no record with the same
+   hash and URI fields.  Note that in the (unlikely) event of hash
+   collision, the given object will not replace the object in the store.
+
+5.1.2.  Get Objects by Hash
+
+   Retrieve all objects from the store whose hash attribute matches the
+   given hash.
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 12]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+5.1.3.  Get Certificate Objects by URI
+
+   Retrieve from the store all objects of type certificate whose URI
+   attribute matches the given URI.
+
+5.1.4.  Get Manifest Objects by AKI
+
+   Retrieve from the store all objects of type manifest whose AKI
+   attribute matches the given AKI.
+
+5.1.5.  Delete Objects for a URI
+
+   For a given URI, delete all objects in the store with a matching URI
+   attribute.
+
+5.1.6.  Delete Outdated Objects
+
+   For a given URI and a list of hashes, delete all objects in the store
+   with a matching URI whose hash attribute is not in the given list of
+   hashes.
+
+5.1.7.  Update Object's Validation Time
+
+   For all objects in the store whose hash attribute matches the given
+   hash, set the last validation time attribute to the given timestamp.
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  Security Considerations
+
+7.1.  Hash Collisions
+
+   This implementation will not detect possible hash collisions in the
+   hashes of repository objects (calculated using the file hash
+   algorithm specified in [RFC7935]).  It considers objects with same
+   hash values to be identical.
+
+7.2.  Algorithm Agility
+
+   This implementation only supports hash algorithms and key sizes
+   specified in [RFC7935].  Algorithm agility described in [RFC6916] is
+   not supported.
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 13]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+7.3.  Mismatch between the Expected and Actual Location of an Object in
+      the Repository
+
+   According to Section 2 of [RFC6481], all objects issued by a
+   particular CA certificate are expected to be located in one
+   repository publication point, specified in the SIA extension of that
+   CA certificate.  The manifest object issued by that CA certificate
+   enumerates all other issued objects, listing their filenames and
+   content hashes.
+
+   However, it is possible that an object whose content hash matches the
+   hash listed in the manifest either has a different filename or is
+   located at a different publication point in a repository.
+
+   On the other hand, all RPKI objects, either explicitly or within
+   their embedded EE certificate, have an AKI extension that contains
+   the key identifier of their issuing CA certificate.  Therefore, it is
+   always possible to perform an RPKI validation of the object whose
+   expected location does not match its actual location, provided that
+   the certificate that matches the AKI of the object in question is
+   known to the system that performs validation.
+
+   In the case of a mismatch as described above, this implementation
+   will not exclude an object from further validation merely because its
+   actual location or filename does not match the expected location or
+   filename.  This decision was made because the actual location of a
+   file in a repository is taken from the repository retrieval
+   mechanism, which, in the case of an rsync repository, does not
+   provide any cryptographic security, and in the case of an RRDP
+   repository, provides only a transport-layer security with the
+   fallback to unsecured transport.  On the other hand, the manifest is
+   an RPKI signed object, and its content could be verified in the
+   context of the RPKI validation.
+
+7.4.  Manifest Content versus Publication Point Content
+
+   This algorithm uses the content of a manifest object to determine
+   other objects issued by a CA certificate.  It verifies that the
+   manifest is located in the publication point designated in the CA
+   certificate's SIA extension.  However, if there are other (not listed
+   in the manifest) objects located in the same publication point
+   directory, they are ignored even if they might be valid and issued by
+   the same CA as the manifest.  (This RP behavior is allowed, but not
+   required, by [RFC6486].)
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 14]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+7.5.  Possible Denial of Service
+
+   The store cleanup procedure described in Section 3.3 tries to
+   minimize 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 (see Section 4.1.1)
+   before they are validated and discarded, leading to out-of-memory or
+   out-of-disk-space conditions and, subsequently, a denial of service.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
+              Housley, R., and W. Polk, "Internet X.509 Public Key
+              Infrastructure Certificate and Certificate Revocation List
+              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
+              <https://www.rfc-editor.org/info/rfc5280>.
+
+   [RFC6481]  Huston, G., Loomans, R., and G. Michaelson, "A Profile for
+              Resource Certificate Repository Structure", RFC 6481,
+              DOI 10.17487/RFC6481, February 2012,
+              <https://www.rfc-editor.org/info/rfc6481>.
+
+   [RFC6482]  Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
+              Origin Authorizations (ROAs)", RFC 6482,
+              DOI 10.17487/RFC6482, February 2012,
+              <https://www.rfc-editor.org/info/rfc6482>.
+
+   [RFC6486]  Austein, R., Huston, G., Kent, S., and M. Lepinski,
+              "Manifests for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
+              <https://www.rfc-editor.org/info/rfc6486>.
+
+   [RFC6487]  Huston, G., Michaelson, G., and R. Loomans, "A Profile for
+              X.509 PKIX Resource Certificates", RFC 6487,
+              DOI 10.17487/RFC6487, February 2012,
+              <https://www.rfc-editor.org/info/rfc6487>.
+
+   [RFC6488]  Lepinski, M., Chi, A., and S. Kent, "Signed Object
+              Template for the Resource Public Key Infrastructure
+              (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
+              <https://www.rfc-editor.org/info/rfc6488>.
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 15]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+   [RFC6493]  Bush, R., "The Resource Public Key Infrastructure (RPKI)
+              Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
+              February 2012, <https://www.rfc-editor.org/info/rfc6493>.
+
+   [RFC6916]  Gagliano, R., Kent, S., and S. Turner, "Algorithm Agility
+              Procedure for the Resource Public Key Infrastructure
+              (RPKI)", BCP 182, RFC 6916, DOI 10.17487/RFC6916, April
+              2013, <https://www.rfc-editor.org/info/rfc6916>.
+
+   [RFC7730]  Huston, G., Weiler, S., Michaelson, G., and S. Kent,
+              "Resource Public Key Infrastructure (RPKI) Trust Anchor
+              Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
+              <https://www.rfc-editor.org/info/rfc7730>.
+
+   [RFC7935]  Huston, G. and G. Michaelson, Ed., "The Profile for
+              Algorithms and Key Sizes for Use in the Resource Public
+              Key Infrastructure", RFC 7935, DOI 10.17487/RFC7935,
+              August 2016, <https://www.rfc-editor.org/info/rfc7935>.
+
+   [RFC8182]  Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
+              "The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
+              DOI 10.17487/RFC8182, July 2017,
+              <https://www.rfc-editor.org/info/rfc8182>.
+
+   [RFC8360]  Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
+              Newton, A., and D. Shaw, "Resource Public Key
+              Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
+              DOI 10.17487/RFC8360, April 2018,
+              <https://www.rfc-editor.org/info/rfc8360>.
+
+8.2.  Informative References
+
+   [rpki-validator]
+              "RIPE-NCC/rpki-validator source code",
+              <https://github.com/RIPE-NCC/rpki-validator>.
+
+   [rsync]    "rsync", October 2018, <https://rsync.samba.org>.
+
+Acknowledgements
+
+   This document describes the algorithm as it is implemented by the
+   software development team at the RIPE NCC, which, over time, included
+   Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da
+   Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo
+   Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn
+   Visinescu.  The authors would also like to acknowledge contributions
+   by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 16]
+
+RFC 8488                  RPKI Tree Validation             December 2018
+
+
+Authors' Addresses
+
+   Oleg Muravskiy
+   RIPE NCC
+
+   Email: oleg@ripe.net
+   URI:   https://www.ripe.net/
+
+
+   Tim Bruijnzeels
+   NLnet Labs
+
+   Email: tim@nlnetlabs.nl
+   URI:   https://www.nlnetlabs.nl/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Muravskiy & Bruijnzeels       Informational                    [Page 17]
+