draft-ietf-sidr-rpki-tree-validation-00.txt   draft-ietf-sidr-rpki-tree-validation-01.txt 
SIDR O. Muravskiy SIDR O. Muravskiy
Internet-Draft T. Bruijnzeels Internet-Draft T. Bruijnzeels
Intended status: Informational RIPE NCC Intended status: Informational RIPE NCC
Expires: September 22, 2016 March 21, 2016 Expires: January 9, 2017 July 8, 2016
RPKI Certificate Tree Validation by a Relying Party Tool RPKI Certificate Tree Validation by a Relying Party Tool
draft-ietf-sidr-rpki-tree-validation-00 draft-ietf-sidr-rpki-tree-validation-01
Abstract Abstract
This document currently describes the approach to validate the This document describes the approach to validate the content of the
content of the RPKI certificate tree, as used by the RIPE NCC RPKI RPKI certificate tree, as used by the RIPE NCC RPKI Validator. This
Validator. This approach is independent of a particular object approach is independent of a particular object retrieval mechanism.
retrieval mechanism. This allows it to be used with repositories This allows it to be used with repositories available over the rsync
available over the rsync protocol, the RPKI Repository Delta protocol, the RPKI Repository Delta Protocol, and repositories that
Protocol, and repositories that use a mix of both. use a mix of both.
This algorithm does not rely on content of repository directories, This algorithm does not rely on content of repository directories,
but uses the Authority Key Identifier (AKI) field of a manifest and a but uses the Authority Key Identifier (AKI) field of a manifest and a
certificate revocation list (CRL) objects to discover manifest and certificate revocation list (CRL) objects to discover manifest and
CRL objects issued by a particular Certificate Authority (CA). It CRL objects issued by a particular Certificate Authority (CA). It
further uses the hashes of manifest entries to discover other objects further uses the hashes of manifest entries to discover other objects
issued by the CA. issued by the CA.
If the working group finds that algorithm outlined here is useful for
other implementations, we may either update future revisions of this
document to be less specific to the RIPE NCC RPKI Validator
implementation, or we may use this document as a starting point of a
generic validation document and keep this as a detailed description
of the actual RIPE NCC RPKI Validator implementation.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Top-down Validation of a Single Trust Anchor Certificate Tree 3 2. General Considerations . . . . . . . . . . . . . . . . . . . 3
2.1. Fetching the Trust Anchor Certificate Using the Trust 2.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 3
2.2. Manifest entries versus repository content . . . . . . . 4
3. Top-down Validation of a Single Trust Anchor Certificate Tree 4
3.1. Fetching the Trust Anchor Certificate Using the Trust
Anchor Locator . . . . . . . . . . . . . . . . . . . . . 4 Anchor Locator . . . . . . . . . . . . . . . . . . . . . 4
2.2. Resource Certificate Validation . . . . . . . . . . . . . 4 3.2. Resource Certificate Validation . . . . . . . . . . . . . 5
2.2.1. Finding most recent valid manifest and CRL . . . . . 5 3.2.1. Finding the most recent valid manifest and CRL . . . 6
2.2.2. Manifest entries validation . . . . . . . . . . . . . 6 3.2.2. Manifest entries validation . . . . . . . . . . . . . 7
2.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 6 3.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 7
3. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 6 4. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 8
3.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 7 4.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 8
3.1.1. Fetch repository objects . . . . . . . . . . . . . . 7 4.1.1. Fetch repository objects . . . . . . . . . . . . . . 8
3.1.2. Fetch single repository object . . . . . . . . . . . 7 4.1.2. Fetch single repository object . . . . . . . . . . . 9
4. Local Object Store . . . . . . . . . . . . . . . . . . . . . 8 5. Local Object Store . . . . . . . . . . . . . . . . . . . . . 9
4.1. Store Operations . . . . . . . . . . . . . . . . . . . . 8 5.1. Store Operations . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Store Repository Object . . . . . . . . . . . . . . . 8 5.1.1. Store Repository Object . . . . . . . . . . . . . . . 9
4.1.2. Update object's last fetch time . . . . . . . . . . . 8 5.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 9
4.1.3. Get objects by hash . . . . . . . . . . . . . . . . . 8 5.1.3. Get certificate objects by URI . . . . . . . . . . . 10
4.1.4. Get certificate objects by URI . . . . . . . . . . . 8 5.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 10
4.1.5. Get manifest objects by AKI . . . . . . . . . . . . . 8 5.1.5. Delete objects for a URI . . . . . . . . . . . . . . 10
4.1.6. Delete objects for URI . . . . . . . . . . . . . . . 8 5.1.6. Delete outdated objects . . . . . . . . . . . . . . . 10
4.1.7. Delete outdated objects . . . . . . . . . . . . . . . 8 5.1.7. Update object's validation time . . . . . . . . . . . 10
4.1.8. Update object's validation time . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
In order to use information published in RPKI repositories, Relying In order to use information published in RPKI repositories, Relying
Parties (RP) need to retrieve and validate the content of Parties (RP) need to retrieve and validate the content of
certificates, CRLs, and other RPKI signed objects. To validate a certificates, CRLs, and other RPKI signed objects. To validate a
particular object, one must ensure that all certificates in the particular object, one must ensure that all certificates in the
certificate chain up to the Trust Anchor (TA) are valid. Therefore certificate chain up to the Trust Anchor (TA) are valid. Therefore
the validation of a certificate tree is usually performed top-down, the validation of a certificate tree is usually performed top-down,
starting from the TA certificate and descending down the certificate starting from the TA certificate and descending down the certificate
chain, validating every encountered certificate and its products. chain, validating every encountered certificate and its products.
The result of this process is a list of all encountered RPKI objects 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 with a validity status attached to each of them. These results may
later be used by a Relying Party in taking routing decisions, etc. later be used by a Relying Party in taking routing decisions, etc.
Traditionally RPKI data is made available to RPs through the Traditionally RPKI data is made available to RPs through the
repositories [RFC6481] accessible over rsync protocol. Relying repositories [RFC6481] accessible over rsync protocol. Relying
parties are advised to keep a local copy of repository data, and parties are advised to keep a local copy of repository data, and
perform regular updates of this copy from the repository (Section 5 perform regular updates of this copy from the repository (Section 5
of[RFC6481]). The RPKI Repository Delta Protocol of [RFC6481]). The RPKI Repository Delta Protocol
[I-D.ietf-sidr-delta-protocol] introduces another method to fetch [I-D.ietf-sidr-delta-protocol] introduces another method to fetch
repository data and keep the local copy up to date with the repository data and keep the local copy up to date with the
repository. repository.
This document describes how a Relying Party tool could discover RPKI This document describes how the RIPE NCC RPKI Validator discovers
objects to download, build certificate path, and validate RPKI RPKI objects to download, builds certificate paths, and validates
objects, independently from what repository access protocol is used. RPKI objects, independently from what repository access protocol is
To achieve this, it puts downloaded RPKI objects in an object store, used. To achieve this, it puts downloaded RPKI objects in an object
where objects could be found by their URI, hash of their content, store, where objects could be found by their URI, hash of their
value of the object's AKI field, or combination of these. It also content, value of the object's AKI field, or combination of these.
keeps track of download and validation time for every object, to It also keeps track of download and validation time for every object,
perform cleanups of the local copy. to perform cleanups of the local copy.
2. Top-down Validation of a Single Trust Anchor Certificate Tree 2. General Considerations
The validation of a Trust Anchor (TA) certificate tree starts from 2.1. Hash comparisons
its TA certificate. To retrieve the TA certificate, a Trust Anchor
Locator (TAL) object is used, as described in Section 2.1.
If the TA certificate is retrieved, it is validated according to the This algorithm relies on the properties of the file hash algorithm
Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. (defined in [RFC6485]) to compute the hash of repository objects. It
assumes that any two objects for which the hash value is the same,
are identical.
Then the TA certificate and all its subordinate objects are validated The hash comparison is used when matching objects in the repository
as described in Section 2.2. with entries on the manifest, and when looking up objects in the
object store (Section 5).
For all repository objects that were validated during this validation 2.2. Manifest entries versus repository content
run, their validation timestamp is updated in an object store (see
Section 4.1.8).
Outdated objects are removed from the store as described in There are several possible ways of discovering products of a CA
Section 2.3. This completes the validation of the TA certificate certificate: one could use all objects located in a repository
tree. 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 [RFC6486]), or use all objects whose AKI field matches
the SKI field of a CA certificate.
2.1. Fetching the Trust Anchor Certificate Using the Trust Anchor Since the current set of RPKI standards requires use of the manifest
[RFC6486] 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 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.
3. Top-down Validation of a Single Trust Anchor Certificate Tree
1. 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 Section 3.1.
2. If the TA certificate is retrieved, it is validated according to
the Section 7 of [RFC6487] and Section 2.2 of [RFC7730].
3. If the TA certificate is valid, then all its subordinate objects
are validated as described in Section 3.2. Otherwise the
validation of certificate tree is aborted and an error is issued.
4. For all repository objects that were validated during this
validation run, their validation timestamp is updated in an
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 Locator
The following steps are performed in order to fetch the Trust Anchor The following steps are performed in order to fetch the Trust Anchor
Certificate: Certificate:
o (Optional) If the Trust Anchor Locator contains a "prefetch.uris" 1. (Optional) If the Trust Anchor Locator contains a "prefetch.uris"
field, pass the URIs contained there to the fetcher (see field, pass the URIs contained in that field to the fetcher (see
Section 3.1.1). (This field is a non-standard extension to the Section 4.1.1). (This field is a non-standard extension to the
TAL format supported by the RIPE NCC Validator. It helps fetching TAL format. It helps fetching non-hierarchical rsync
non-hierarchical rsync repositories more efficiently.) repositories more efficiently.)
o Extract the TA certificate URI from the TAL's URI section (see 2. Extract the TA certificate URI from the TAL's URI section (see
Section 2.1 of[RFC7730]) and pass to the object fetcher Section 2.1 of [RFC7730]) and pass it to the object fetcher
(Section 3.1.2). (Section 4.1.2).
o Retrieve from the object store (see Section 4.1.4) all certificate 3. Retrieve from the object store (see Section 5.1.3) all
objects, for which the URI matches the URI extracted from the TAL certificate objects, for which the URI matches the URI extracted
in the previous step, and the public key matches the from the TAL in the previous step, and the public key matches the
subjectPublicKeyInfo field of the TAL (see Section 2.1 of subjectPublicKeyInfo field of the TAL (see Section 2.1 of
[RFC7730]). [RFC7730]).
o If no, or more than one such objects are found, issue an error and 4. If no, or more than one such objects are found, issue an error
stop validation process. Otherwise, use that object as the Trust and abort certificate tree validation process with an error.
Anchor certificate. Otherwise, use the single found object as the Trust Anchor
certificate.
2.2. Resource Certificate Validation 3.2. Resource Certificate Validation
The following steps describe the validation of a single resource The following steps describe the validation of a single resource
certificate: certificate:
o If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the 1. If both the caRepository (Section 4.8.8.1 of [RFC6487]), and the
id-ad-rpkiNotify (Section 3.5 of [I-D.ietf-sidr-delta-protocol]) id-ad-rpkiNotify (Section 3.5 of [I-D.ietf-sidr-delta-protocol])
SIA pointers are present in the given resource certificate, use a SIA pointers are present in the given resource certificate, use a
local policy to determine which pointer to use. Extract the URI local policy to determine which pointer to use. Extract the URI
from the selected pointer and pass it to the object fetcher (see from the selected pointer and pass it to the object fetcher (see
Section 3.1.1). Section 4.1.1).
o For a given resource certificate, find its manifest and 2. For a given resource certificate, find its manifest and
certificate revocation list (CRL), using the procedure described certificate revocation list (CRL), using the procedure described
in Section 2.2.1. If no such manifest and CRL could be found, in Section 3.2.1. If no such manifest and CRL could be found,
issue an error and stop processing current certificate. stop validation of this certificate, consider it invalid, and
issue an error.
o Compare the URI found in the given resource certificate's id-ad- 3. Compare the URI found in the given resource certificate's id-ad-
rpkiManifest field (Section 4.8.8.1 of [RFC6487]) with the URI of rpkiManifest field (Section 4.8.8.1 of [RFC6487]) with the URI of
the manifest found in the previous step. If they are different, the manifest found in the previous step. If they are different,
issue a warning. issue a warning.
o Perform manifest entries validation as described in Section 2.2.2. 4. Perform manifest entries discovery and validation as described in
Section 3.2.2.
o Validate all resource certificate objects found on the manifest, 5. Validate all resource certificate objects found on the manifest,
using the CRL object found on the manifest, according to Section 7 using the CRL object found on the manifest, according to
of [RFC6487]. Section 7 of [RFC6487].
o Validate all ROA objects found on the manifest, using the CRL 6. Validate all ROA objects found on the manifest, using the CRL
object found on the manifest, according to the Section 4 of object found on the manifest, according to the Section 4 of
[RFC6482]. [RFC6482].
o Validate all Ghostbusters Record objects found on the manifest, 7. Validate all Ghostbusters Record objects found on the manifest,
using the CRL object found on the manifest, according to the using the CRL object found on the manifest, according to the
Section 7 of [RFC6493]. Section 7 of [RFC6493].
o For every valid resource certificate object found on the manifest, 8. For every valid resource certificate object found on the
apply the procedure described in this section (Section 2.2), manifest, apply the procedure described in this section
recursively, provided that this resource certificate (identified (Section 3.2), recursively, provided that this resource
by its SKI) has not yet been validated during current repository certificate (identified by its SKI) has not yet been validated
validation run. during current repository validation run.
2.2.1. Finding most recent valid manifest and CRL 3.2.1. Finding the most recent valid manifest and CRL
Fetch from the store (see Section 4.1.5) all objects of type 1. Fetch from the store (see Section 5.1.4) all objects of type
manifest, whose certificate's AKI field matches the SKI of the manifest, whose certificate's AKI field matches the SKI of the
current CA certificate. current CA certificate. If no such objects are found, stop
processing current resource certificate and issue an error.
Find the manifest object with the highest manifestNumber field 2. Find among found objects the manifest object with the highest
(Section 4.2.1 of [RFC6486]), for which all following conditions are manifestNumber field (Section 4.2.1 of [RFC6486]), for which all
met: following conditions are met:
o There is only one entry in the manifest for which the store * There is only one entry in the manifest for which the store
contains exactly one object of type CRL, whose hash matches the contains exactly one object of type CRL, whose hash matches
hash of the entry. the hash of the entry.
o The manifest's certificate AKI equals the above CRL's AKI * The manifest's certificate AKI equals the above CRL's AKI.
o The above CRL is a valid object according to Section 6.3 of * The above CRL is a valid object according to Section 6.3 of
[RFC5280] [RFC5280].
o The manifest is a valid object according to Section 4.4 of * The manifest is a valid object according to Section 4.4 of
[RFC6486], using the CRL found above [RFC6486], using the CRL found above.
Report an error for every invalid manifest with the number higher 3. If there is an object that matches above criteria, consider this
than the number of the valid manifest. 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.
2.2.2. Manifest entries validation 4. Report an error for every other manifest with a number higher
than the number of the valid manifest.
3.2.2. Manifest entries validation
For every entry in the manifest object: For every entry in the manifest object:
o Construct an entry's URI by appending the entry name to the 1. Construct an entry's URI by appending the entry name to the
current CA's publication point URI. current CA's publication point URI.
o Get all objects from the store whose hash attribute equals entry's 2. Get all objects from the store whose hash attribute equals
hash (see Section 4.1.3). entry's hash (see Section 5.1.2).
o If no such objects found, issue an error. 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.
o For every found object, compare its URI with the URI of the 4. For every found object, compare its URI with the URI of the
manifest entry. If they do not match, issue a warning. manifest entry.
o If no objects with matching URI found, issue a warning. * 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.
o If some objects with non-matching URI found, issue a warning. * 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).
2.3. Object Store Cleanup 5. Use all found objects for further validation.
3.3. Object Store Cleanup
At the end of the TA tree validation the store cleanup is performed: At the end of the TA tree validation the store cleanup is performed:
o Given all objects that were validated during the current 1. Given all objects that were encountered during the current
validation run, remove from the store (Section 4.1.7) all objects validation run, remove from the store (Section 5.1.6) all objects
whose URI attribute matches the URI of one of the validated whose URI attribute matches the URI of one of the encountered
objects, but the content's hash is different. 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.
o Remove from the store all objects that were last validated more 2. Remove from the store all objects that were last encountered
than 7 days ago. 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).
o Remove from the store all objects that were downloaded more than 2 3. Remove from the store all objects that were downloaded recently
hours ago and have never been used in a validation process. (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.
The time intervals used in the steps above are a matter of local Shortening the time interval used in step 2 will free disk space used
policy. by the store, to the expense of downloading removed objects again if
they are still published in the repository.
3. Remote Objects Fetcher 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.
4. Remote Objects Fetcher
The fetcher is responsible for downloading objects from remote The fetcher is responsible for downloading objects from remote
repositories (described in Section 3 of [RFC6481]) using rsync repositories (described in Section 3 of [RFC6481]) using rsync
protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP) protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP)
([I-D.ietf-sidr-delta-protocol]). ([I-D.ietf-sidr-delta-protocol]).
3.1. Fetcher Operations 4.1. Fetcher Operations
3.1.1. Fetch repository objects For every successfully visited URI the fetcher keeps track of the
last time it happened.
4.1.1. Fetch repository objects
This operation receives one parameter - a URI. For rsync protocol This operation receives one parameter - a URI. For rsync protocol
this URI points to a directory in a remote repository. For RRDP this URI points to a directory in a remote repository. For RRDP
repository it points to the repository's notification file. repository it points to the repository's notification file.
The fetcher performs following steps: The fetcher performs following steps:
o If the given URI has been downloaded recently (as specified by the 1. If data associated with the URI has been downloaded recently (as
local policy), skip all following steps. specified by the local policy), skip following steps.
o Download the remote objects using the URI provided (for an rsync 2. Download the remote objects using the URI provided (for an rsync
repository use a recursive mode). repository use a recursive mode).
o For every new object that is downloaded, try to parse it as an 3. For every new object that is downloaded, try to parse it as an
object of specific RPKI type (certificate, manifest, CRL, ROA, object of specific RPKI type (certificate, manifest, CRL, ROA,
Ghostbusters record), based on the object's filename extension Ghostbusters record), based on the object's filename extension
(.cer, .mft, .crl, .roa, and .gbr, respectively), and perform (.cer, .mft, .crl, .roa, and .gbr, respectively), and perform
basic RPKI object validation, as specified in [RFC6487] and basic RPKI object validation (excluding resource certification
[RFC6488]. path validation), as specified in [RFC6487] and [RFC6488].
o For every downloaded valid object, record it in the object store 4. Put every downloaded valid object in the object store
(Section 4.1.1), and set its last fetch time to the time it was (Section 5.1.1).
downloaded (Section 4.1.2).
3.1.2. Fetch single repository object The time interval used in the step 1 should be chosen based on the
acceptable delay in receiving repository updates.
4.1.2. Fetch single repository object
This operation receives one parameter - a URI that points to an This operation receives one parameter - a URI that points to an
object in a remote repository. object in a repository.
The fetcher performs following operations: The fetcher performs following operations:
o If the given URI has been downloaded recently (as specified by the 1. If data associated with the URI has been downloaded recently (as
local policy), skip all following steps. specified by the local policy), skip all following steps.
o Download the remote object using the URI provided. 2. Download the remote object using the URI provided.
o Try to parse the downloaded object as an object of a specific RPKI 3. Try to parse the downloaded object as an object of a specific
type (certificate, manifest, CRL, ROA, Ghostbusters record), based RPKI type (certificate, manifest, CRL, ROA, Ghostbusters record),
on the object's filename extension (.cer, .mft, .crl, .roa, and based on the object's filename extension (.cer, .mft, .crl, .roa,
.gbr, respectively), and perform basic RPKI object validation, as and .gbr, respectively), and perform basic RPKI object validation
specified in [RFC6487] and [RFC6488]. (excluding resource certification path validation), as specified
in [RFC6487] and [RFC6488].
o If the downloaded object is not valid, issue an error and skip 4. If the downloaded object is not valid, issue an error and skip
further steps. further steps.
o Delete objects from the object store (Section 4.1.6) whose URI 5. Delete all objects from the object store (Section 5.1.5) whose
matches the URI given. URI matches the URI given.
o Put validated object in the object store (Section 4.1.1), and set 6. Put the validated object in the object store (Section 5.1.1).
its last fetch time to the time it was downloaded (Section 4.1.2).
4. Local Object Store 5. Local Object Store
4.1. Store Operations 5.1. Store Operations
4.1.1. Store Repository Object 5.1.1. Store Repository Object
Put given object in the store, along with its type, URI, hash, and 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. AKI, if there is no record with the same hash and URI fields.
4.1.2. Update object's last fetch time 5.1.2. Get objects by hash
For all objects in the store whose URI matches the given URI, set the
last fetch time attribute to the given timestamp.
4.1.3. Get objects by hash
Retrieve all objects from the store whose hash attribute matches the Retrieve all objects from the store whose hash attribute matches the
given hash. given hash.
4.1.4. Get certificate objects by URI 5.1.3. Get certificate objects by URI
Retrieve from the store all objects of type certificate, whose URI Retrieve from the store all objects of type certificate, whose URI
attribute matches the given URI. attribute matches the given URI.
4.1.5. Get manifest objects by AKI 5.1.4. Get manifest objects by AKI
Retrieve from the store all objects of type manifest, whose AKI Retrieve from the store all objects of type manifest, whose AKI
attribute matches the given AKI. attribute matches the given AKI.
4.1.6. Delete objects for URI 5.1.5. Delete objects for a URI
For a given URI, delete all objects in the store with matching URI For a given URI, delete all objects in the store with matching URI
attribute. attribute.
4.1.7. Delete outdated objects 5.1.6. Delete outdated objects
For a given URI and a list of hashes, delete all objects in the store 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 with matching URI, whose hash attribute is not in the given list of
hashes. hashes.
4.1.8. Update object's validation time 5.1.7. Update object's validation time
For all objects in the store whose hash attribute matches the given For all objects in the store whose hash attribute matches the given
hash, set the last validation time attribute to the given timestamp. hash, set the last validation time attribute to the given timestamp.
5. Acknowledgements 6. Acknowledgements
This document describes the algorithm as it is implemented by the This document describes the algorithm as it is implemented by the
software development team at the RIPE NCC. The original idea behind software development team at the RIPE NCC. The authors would also
it was outlined by Tim Bruijnzeels. The authors would also like to like to acknowledge contributions by Carlos Martinez, Andy Newton,
acknowledge contributions by Carlos Martinez, Andy Newton, and Rob and Rob Austein.
Austein.
6. IANA Considerations 7. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Security Considerations 8. Security Considerations
This implementation will not detect possible hash collisions in the
hashes of repository objects (calculated using the file hash
algorithm specified in [RFC6485]), and considers objects with same
hash values as identical.
This algorithm uses the content of a manifest object to discover This algorithm uses the content of a manifest object to discover
other objects issued by a particular CA. It verifies that the other objects issued by a specified CA. It verifies that the
manifest is located in the publication point designated in the CA manifest is located in the publication point designated in the CA
Certificate. However, if there are other (not enlisted in the Certificate. However, if there are other (not listed in the
manifest) objects located in that publication point directory, they manifest) objects located in that publication point directory, they
will be ignored, even if their content is correct and they are issued will be ignored, even if their content is correct and they are issued
by the same CA as the manifest. by the same CA as the manifest.
In contrast, objects whose content hash matches the hash listed in In contrast, objects whose content hash matches the hash listed in
the manifest, but that are not located in the publication directory the manifest, but that are not located in the publication directory
listed in their CA certificate, will be used in the validation listed in their CA certificate, will be used in the validation
process (although a warning will be issued in that case). process (although a warning will be issued in that case).
The store cleanup procedure described in Section 2.3 tries to The store cleanup procedure described in Section 3.3 tries to
minimise removal and subsequent re-fetch of objects that are minimise removal and subsequent re-fetch of objects that are
published in some repository but not used in the validation. Once published in a repository but not used in the validation. Once such
such objects are removed from the remote repository, they will be objects are removed from the remote repository, they will be
discarded from the local object store after a period of time discarded from the local object store after a period of time
specified by a local policy. By generating an excessive amount of specified by a local policy. By generating an excessive amount of
syntactically valid RPKI objects, a man-in-the-middle attack rendered syntactically valid RPKI objects, a man-in-the-middle attack between
between a validating tool and a repository could force an a validating tool and a repository could force an implementation to
implementation to fetch and store those objects in the object store fetch and store those objects in the object store before they are
before they are being validated and discarded, leading to an out-of- validated and discarded, leading to an out-of-memory or out-of-disk-
memory or out-of-disk-space conditions, and, subsequently, a denial space conditions, and, subsequently, a denial of service.
of service.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for [RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
Resource Certificate Repository Structure", RFC 6481, Resource Certificate Repository Structure", RFC 6481,
DOI 10.17487/RFC6481, February 2012, DOI 10.17487/RFC6481, February 2012,
<http://www.rfc-editor.org/info/rfc6481>. <http://www.rfc-editor.org/info/rfc6481>.
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route [RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route
Origin Authorizations (ROAs)", RFC 6482, Origin Authorizations (ROAs)", RFC 6482,
DOI 10.17487/RFC6482, February 2012, DOI 10.17487/RFC6482, February 2012,
<http://www.rfc-editor.org/info/rfc6482>. <http://www.rfc-editor.org/info/rfc6482>.
[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
Use in the Resource Public Key Infrastructure (RPKI)",
RFC 6485, DOI 10.17487/RFC6485, February 2012,
<http://www.rfc-editor.org/info/rfc6485>.
[RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski, [RFC6486] Austein, R., Huston, G., Kent, S., and M. Lepinski,
"Manifests for the Resource Public Key Infrastructure "Manifests for the Resource Public Key Infrastructure
(RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012, (RPKI)", RFC 6486, DOI 10.17487/RFC6486, February 2012,
<http://www.rfc-editor.org/info/rfc6486>. <http://www.rfc-editor.org/info/rfc6486>.
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for [RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
X.509 PKIX Resource Certificates", RFC 6487, X.509 PKIX Resource Certificates", RFC 6487,
DOI 10.17487/RFC6487, February 2012, DOI 10.17487/RFC6487, February 2012,
<http://www.rfc-editor.org/info/rfc6487>. <http://www.rfc-editor.org/info/rfc6487>.
skipping to change at page 11, line 5 skipping to change at page 12, line 29
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) [RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI)
Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493,
February 2012, <http://www.rfc-editor.org/info/rfc6493>. February 2012, <http://www.rfc-editor.org/info/rfc6493>.
[RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent, [RFC7730] Huston, G., Weiler, S., Michaelson, G., and S. Kent,
"Resource Public Key Infrastructure (RPKI) Trust Anchor "Resource Public Key Infrastructure (RPKI) Trust Anchor
Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016, Locator", RFC 7730, DOI 10.17487/RFC7730, January 2016,
<http://www.rfc-editor.org/info/rfc7730>. <http://www.rfc-editor.org/info/rfc7730>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-sidr-delta-protocol] [I-D.ietf-sidr-delta-protocol]
Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R., Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R.,
and D. Mandelberg, "RPKI Repository Delta Protocol", and D. Mandelberg, "RPKI Repository Delta Protocol",
draft-ietf-sidr-delta-protocol-02 (work in progress), draft-ietf-sidr-delta-protocol-02 (work in progress),
March 2016. March 2016.
[rsync] "Rsync home page", <https://rsync.samba.org>. [rsync] "Rsync home page", <https://rsync.samba.org>.
Authors' Addresses Authors' Addresses
 End of changes. 86 change blocks. 
218 lines changed or deleted 287 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/