draft-ietf-sidrops-rpki-tree-validation-02.txt   draft-ietf-sidrops-rpki-tree-validation-03.txt 
SIDR Operations O. Muravskiy SIDR Operations O. Muravskiy
Internet-Draft RIPE NCC Internet-Draft RIPE NCC
Intended status: Informational T. Bruijnzeels Intended status: Informational T. Bruijnzeels
Expires: December 30, 2018 NLNetLabs Expires: March 20, 2019 NLNetLabs
June 28, 2018 September 16, 2018
RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator
draft-ietf-sidrops-rpki-tree-validation-02 draft-ietf-sidrops-rpki-tree-validation-03
Abstract Abstract
This document describes the approach to validate the content of the This document describes the approach to validate the content of the
RPKI certificate tree, as it is implemented in the RIPE NCC RPKI RPKI certificate tree, as it is implemented in the RIPE NCC RPKI
Validator. This approach is independent of a particular object Validator. This approach is independent of a particular object
retrieval mechanism. This allows it to be used with repositories retrieval mechanism. This allows it to be used with repositories
available over the rsync protocol, the RPKI Repository Delta available over the rsync protocol, the RPKI Repository Delta
Protocol, and repositories that use a mix of both. Protocol, and repositories that use a mix of both.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 30, 2018. This Internet-Draft will expire on March 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 39 skipping to change at page 2, line 39
6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11 6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11
6.1.3. Get certificate objects by URI . . . . . . . . . . . 11 6.1.3. Get certificate objects by URI . . . . . . . . . . . 11
6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11 6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11
6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12 6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12
6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12 6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12
6.1.7. Update object's validation time . . . . . . . . . . . 12 6.1.7. Update object's validation time . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12 9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12
9.2. Mismatch between the expected and the actual location of 9.2. Algorithm agility . . . . . . . . . . . . . . . . . . . . 12
an object in the repository . . . . . . . . . . . . . . . 12 9.3. Mismatch between the expected and the actual location of
9.3. Manifest content versus publication point content . . . . 13 an object in the repository . . . . . . . . . . . . . . . 13
9.4. Storing of a TA certificate object before its complete 9.4. Manifest content versus publication point content . . . . 13
validation . . . . . . . . . . . . . . . . . . . . . . . 13
9.5. Possible denial of service . . . . . . . . . . . . . . . 14 9.5. Possible denial of service . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15 10.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Scope of this document 1. Scope of this document
This document describes how the RIPE NCC RPKI Validator version 2.23 This document describes how the RIPE NCC RPKI Validator version 2.23
has been implemented. Source code to this software can be found at has been implemented. Source code to this software can be found at
skipping to change at page 3, line 34 skipping to change at page 3, line 34
down the certificate chain, validating every encountered certificate down the certificate chain, validating every encountered certificate
and its products. The result of this process is a list of all and its products. The result of this process is a list of all
encountered RPKI objects with a validity status attached to each of encountered RPKI objects with a validity status attached to each of
them. These results may later be used by a Relying Party in taking them. These results may later be used by a Relying Party in taking
routing decisions, etc. 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 [RFC8182]
[I-D.ietf-sidr-delta-protocol] introduces another method to fetch introduces another method to fetch repository data and keep the local
repository data and keep the local copy up to date with the copy up to date with the repository.
repository.
This document describes how the RIPE NCC RPKI Validator discovers This document describes how the RIPE NCC RPKI Validator discovers
RPKI objects to download, builds certificate paths, and validates RPKI objects to download, builds certificate paths, and validates
RPKI objects, independently from what repository access protocol is RPKI objects, independently from what repository access protocol is
used. To achieve this, it puts downloaded RPKI objects in an object 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 store, where each RPKI object can be found by its URI, the hash of
its content, value of its Authority Key Identifier (AKI) extension, its content, value of its Authority Key Identifier (AKI) extension,
or a combination of these. It also keeps track of the download and or a combination of these. It also keeps track of the download and
the validation time for every object, to decide which locally stored the validation time for every object, to decide which locally stored
objects are not used in the RPKI tree validation and could be objects are not used in the RPKI tree validation and could be
removed. removed.
3. General Considerations 3. General Considerations
3.1. Hash comparisons 3.1. Hash comparisons
This algorithm relies on the properties of the file hash algorithm This algorithm relies on the collision resistance properties of the
(defined in [RFC6485]) to compute the hash of repository objects. It file hash algorithm (defined in [RFC7935]) to compute the hash of
assumes that any two objects for which the hash value is the same, repository objects. It assumes that any two objects for which the
are identical. hash value is the same, are identical.
The hash comparison is used when matching objects in the repository The hash comparison is used when matching objects in the repository
with entries on the manifest (Section 4.2.2), and when looking up with entries on the manifest (Section 4.2.2), and when looking up
objects in the object store (Section 6). objects in the object store (Section 6).
3.2. Discovery of RPKI objects issued by a CA 3.2. Discovery of RPKI objects issued by a CA
There are several possible ways of discovering products of a CA There are several possible ways of discovering potential products of
certificate: one could use all objects located in a repository a CA certificate: one could use all objects located in a repository
directory designated as a publication point for a CA, or only objects directory designated as a publication point for a CA, or only objects
mentioned on the manifest located at that publication point (see mentioned on the manifest located at that publication point (see
Section 6 of [RFC6486]), or use all objects whose AKI extension Section 6 of[RFC6486]), or use all known repository objects whose AKI
matches the Subject Key Identifier (SKI) extension (Section 4.2.1 of extension matches the Subject Key Identifier (SKI) extension
[RFC5280]) of a CA certificate. (Section 4.2.1 of[RFC5280]) of a CA certificate.
For publication points whose content is consistent with the manifest For publication points whose content is consistent with the manifest
and issuing certificate all of these approaches should produce the and issuing certificate all of these approaches should produce the
same result. For inconsistent publication points the results might same result. For inconsistent publication points the results might
be different. Section 6 of [RFC6486] leaves the decision on how to be different. Section 6 of [RFC6486] leaves the decision on how to
deal with inconsistencies to a local policy. deal with inconsistencies to a local policy.
The implementation described here does not rely on content of The implementation described here does not rely on content of
repository directories, but uses the Authority Key Identifier (AKI) repository directories, but uses the Authority Key Identifier (AKI)
extension of a manifest and a certificate revocation list (CRL) to extension of a manifest and a certificate revocation list (CRL) to
skipping to change at page 6, line 18 skipping to change at page 6, line 18
and abort certificate tree validation process with an error. and abort certificate tree validation process with an error.
Otherwise, use the single found object as the Trust Anchor Otherwise, use the single found object as the Trust Anchor
certificate. certificate.
4.2. CA Certificate Validation 4.2. CA Certificate Validation
The following steps describe the validation of a single CA Resource The following steps describe the validation of a single CA Resource
certificate: certificate:
1. 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.2 of [I-D.ietf-sidr-delta-protocol]) id-ad-rpkiNotify (Section 3.2 of [RFC8182]) SubjectInfoAccess
SIA pointers are present in the CA certificate, use a local (SIA) pointers are present in the CA certificate, use a local
policy to determine which pointer to use. Extract the URI from policy to determine which pointer to use. Extract the URI from
the selected pointer and pass it to the object fetcher (see the selected pointer and pass it to the object fetcher (that will
then fetch all objects available from that repository, see
Section 5.1.1). Section 5.1.1).
2. For the CA certificate, find the current manifest and certificate 2. For the CA certificate, find the current manifest and certificate
revocation list (CRL), using the procedure described in revocation list (CRL), using the procedure described in
Section 4.2.1. If no such manifest and CRL could be found, stop Section 4.2.1. If no such manifest and CRL could be found, stop
validation of this certificate, consider it invalid, and issue an validation of this certificate, consider it invalid, and issue an
error. error.
3. Compare the URI found in the id-ad-rpkiManifest field 3. Compare the URI found in the id-ad-rpkiManifest field
(Section 4.8.8.1 of [RFC6487]) of the SIA extension of the (Section 4.8.8.1 of [RFC6487]) of the SIA extension of the
certificate with the URI of the manifest found in the previous certificate with the URI of the manifest found in the previous
step. If they are different, issue a warning, but continue step. If they are different, issue a warning, but continue
validation process using this manifest object. (This warning validation process using the manifest found in the previous step.
indicates that there is a mismatch between the expected and the (This warning indicates that there is a mismatch between the
actual location of an object in a repository. See Section 9 for expected and the actual location of an object in a repository.
the explanation of this mismatch and the decision taken.) See Section 9 for the explanation of this mismatch and the
decision taken.)
4. Perform manifest entries discovery and validation as described in 4. Perform manifest entries discovery and validation as described in
Section 4.2.2. Section 4.2.2.
5. 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: using the CRL object found on the manifest:
* if the strict validation option is enabled by the operator, * if the strict validation option is enabled by the operator,
the validation is performed according to Section 7 of the validation is performed according to Section 7 of
[RFC6487], [RFC6487],
* otherwise, the validation is performed according to Section 7 * otherwise, the validation is performed according to Section 7
of [RFC6487], with the exception of the resource certification of [RFC6487], with the exception of the resource certification
path validation, that is performed according to path validation, that is performed according to
Section 4.2.4.4 of Section 4.2.4.4 of [RFC8360].
[I-D.ietf-sidr-rpki-validation-reconsidered].
(Note that this implementation uses the operator configuration to (Note that this implementation uses the operator configuration to
decide which algorithm to use for path validation. It applies decide which algorithm to use for path validation. It applies
selected algorithm to all resource certificates, rather than the selected algorithm to all resource certificates, rather than
applying appropriate algorithm per resource certificate, based on applying appropriate algorithm per resource certificate, based on
the object identifier (OID) for the Certificate Policy found in the object identifier (OID) for the Certificate Policy found in
that certificate, as specified in that certificate, as specified in [RFC8360].)
[I-D.ietf-sidr-rpki-validation-reconsidered].)
6. Validate all ROA objects found on the manifest, using the CRL 6. Validate all Route Origin Authorization (ROA) objects found on
object found on the manifest, according to Section 4 of the manifest, using the CRL object found on the manifest,
[RFC6482]. according to Section 4 of [RFC6482].
7. 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 using the CRL object found on the manifest, according to
Section 7 of [RFC6493]. Section 7 of [RFC6493].
8. For every valid CA certificate object found on the manifest, 8. For every valid CA certificate object found on the manifest,
apply the procedure described in this section (Section 4.2), apply the procedure described in this section (Section 4.2),
recursively, provided that this CA certificate (identified by its recursively, provided that this CA certificate (identified by its
SKI) has not yet been validated during current tree validation SKI) has not yet been validated during current tree validation
run. run.
skipping to change at page 8, line 47 skipping to change at page 8, line 51
* If no objects with a matching URI are found, issue a warning. * If no objects with a matching URI are found, issue a warning.
This case indicates that there is no object found in the This case indicates that there is no object found in the
repository at the location listed in the manifest entry (but repository at the location listed in the manifest entry (but
there is at least one matching object found at a different there is at least one matching object found at a different
location). location).
5. Use all found objects for further validation as per Section 4.2. 5. Use all found objects for further validation as per Section 4.2.
Please note that the above steps will not reject objects whose hash Please note that the above steps will not reject objects whose hash
matches the hash listed in the manifest, but the URI does not. See matches the hash listed in the manifest, but the URI does not. See
Section 9.2 for additional information. Section 9.3 for additional information.
4.3. Object Store Cleanup 4.3. Object Store Cleanup
At the end of every TA tree validation some objects are removed from At the end of every TA tree validation some objects are removed from
the store using the following rules: the store using the following rules:
1. Given all objects that were encountered during the current 1. Given all objects that were encountered during the current
validation run, remove from the store (Section 6.1.6) all objects validation run, remove from the store (Section 6.1.6) all objects
whose URI attribute matches the URI of one of the encountered whose URI attribute matches the URI of one of the encountered
objects, but the content's hash is different. This removes from objects, but the content's hash is different. This removes from
skipping to change at page 9, line 42 skipping to change at page 9, line 42
Extending the time interval used in step 3 will prevent repeated Extending the time interval used in step 3 will prevent repeated
downloads of repository objects, with the risk that such objects, if downloads of repository objects, with the risk that such objects, if
created massively by mistake or by an adversary, will fill up local created massively by mistake or by an adversary, will fill up local
disk space, if they are not cleaned up promptly. disk space, if they are not cleaned up promptly.
5. Remote Objects Fetcher 5. 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]). ([RFC8182]).
5.1. Fetcher Operations 5.1. Fetcher Operations
For every visited URI the fetcher keeps track of the last time a For every visited URI the fetcher keeps track of the last time a
successful fetch occurred. successful fetch occurred.
5.1.1. Fetch repository objects 5.1.1. Fetch repository objects
This operation receives one parameter - a URI. For an rsync This operation receives one parameter - a URI. For an rsync
repository this URI points to a directory. For an RRDP repository it repository this URI points to a directory. For an RRDP repository it
skipping to change at page 12, line 24 skipping to change at page 12, line 24
hashes. hashes.
6.1.7. Update object's validation time 6.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.
7. Acknowledgements 7. 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 authors would also software development team at the RIPE NCC, which included over time:
like to acknowledge contributions by Carlos Martinez, Andy Newton, Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da
Rob Austein, and Stephen Kent. 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.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 9. Security Considerations
9.1. Hash collisions 9.1. Hash collisions
This implementation will not detect possible hash collisions in the This implementation will not detect possible hash collisions in the
hashes of repository objects (calculated using the file hash hashes of repository objects (calculated using the file hash
algorithm specified in [RFC6485]). It considers objects with same algorithm specified in [RFC7935]). It considers objects with same
hash values as identical. hash values as identical.
9.2. Mismatch between the expected and the actual location of an object 9.2. Algorithm agility
This implementation only supports hash algorithms and key sizes
specified in [RFC7935]). Algorithm agility described in [RFC6916] is
not supported.
9.3. Mismatch between the expected and the actual location of an object
in the repository in the repository
According to Section 2 of [RFC6481], all objects issued by a According to Section 2 of [RFC6481], all objects issued by a
particular CA certificate are expected to be located in one particular CA certificate are expected to be located in one
repository publication point, specified in the SIA extension of that repository publication point, specified in the SIA extension of that
CA certificate. The manifest object issued by that CA certificate CA certificate. The manifest object issued by that CA certificate
enumerates all other issued objects, listing their file names and enumerates all other issued objects, listing their file names and
content hashes. content hashes.
However, it is possible that an object whose content hash matches the However, it is possible that an object whose content hash matches the
skipping to change at page 13, line 19 skipping to change at page 13, line 29
On the other hand, all RPKI objects, either explicitly or within On the other hand, all RPKI objects, either explicitly or within
their embedded EE certificate, have an Authority Key Identifier their embedded EE certificate, have an Authority Key Identifier
extension that contains the key identifier of their issuing CA extension that contains the key identifier of their issuing CA
certificate. Therefore it is always possible to perform an RPKI certificate. Therefore it is always possible to perform an RPKI
validation of the object whose expected location does not match its validation of the object whose expected location does not match its
actual location, provided that the certificate that matches the AKI actual location, provided that the certificate that matches the AKI
of the object in question is known to the system that performs of the object in question is known to the system that performs
validation. validation.
In case of a mismatch described above this implementation will not In case of a mismatch described above this implementation will not
exclude an object from further validation merely because it's actual exclude an object from further validation merely because its actual
location or file name does not match the expected location or file location or file name does not match the expected location or file
name. This decision was chosen because the actual location of a file name. This decision was chosen because the actual location of a file
in a repository is taken from the repository retrieval mechanism, in a repository is taken from the repository retrieval mechanism,
which, in case of an rsync repository, does not provide any which, in case of an rsync repository, does not provide any
cryptographic security, and in case of an RRDP repository, provides cryptographic security, and in case of an RRDP repository, provides
only a transport layer security, with the fallback to unsecured only a transport layer security, with the fallback to unsecured
transport. On the other hand, the manifest is an RPKI signed object, transport. On the other hand, the manifest is an RPKI signed object,
and its content could be verified in the context of the RPKI and its content could be verified in the context of the RPKI
validation. validation.
9.3. Manifest content versus publication point content 9.4. Manifest content versus publication point content
This algorithm uses the content of a manifest object to determine This algorithm uses the content of a manifest object to determine
other objects issued by a CA certificate. It verifies that the other objects issued by a CA certificate. 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's SIA extension. However, if there are other (not listed Certificate's SIA extension. However, if there are other (not listed
in the manifest) objects located in the same publication point in the manifest) objects located in the same publication point
directory, they are ignored, even if they might be valid and issued directory, they are ignored, even if they might be valid and issued
by the same CA certificate as the manifest. (This behavior is by the same CA as the manifest. (This RP behavior is allowed, but
allowed, but not required, by [RFC6486].) not required, by [RFC6486].)
9.4. Storing of a TA certificate object before its complete validation
When fetching and storing a TA certificate to the object store, only
a syntactic validation of a downloaded object is performed before
newly downloaded object replaces the previously downloaded object in
the object store (see Section 5.1.2). If an attacker will be able to
replace a genuine TA certificate by a syntactically valid certificate
object (either by manipulating the content of a repository, or by a
man-in-the-middle attack), this implementation will discard
previously downloaded genuine object, and replace it by a false
object. Such false object will be detected later, but the validation
of the whole RPKI tree under this TA will be aborted, as described in
Section 4.
9.5. Possible denial of service 9.5. Possible denial of service
The store cleanup procedure described in Section 4.3 tries to The store cleanup procedure described in Section 4.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 a repository, but not used in the validation. Once such published in a repository, but not used in the validation. Once 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 between syntactically valid RPKI objects, a man-in-the-middle attack between
a validating tool and a repository could force an implementation to a validating tool and a repository could force an implementation to
fetch and store those objects in the object store before they are fetch and store those objects in the object store (see Section 5.1.1)
validated and discarded, leading to an out-of-memory or out-of-disk- before they are validated and discarded, leading to an out-of-memory
space conditions, and, subsequently, a denial of service. or out-of-disk-space conditions, and, subsequently, a denial of
service.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-sidr-delta-protocol]
Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
"RPKI Repository Delta Protocol (RRDP)", draft-ietf-sidr-
delta-protocol-08 (work in progress), March 2017.
[I-D.ietf-sidr-rpki-validation-reconsidered]
Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
Newton, A., and D. Shaw, "RPKI Validation Reconsidered",
draft-ietf-sidr-rpki-validation-reconsidered-10 (work in
progress), December 2017.
[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,
<https://www.rfc-editor.org/info/rfc5280>. <https://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,
<https://www.rfc-editor.org/info/rfc6481>. <https://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,
<https://www.rfc-editor.org/info/rfc6482>. <https://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,
<https://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,
<https://www.rfc-editor.org/info/rfc6486>. <https://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,
<https://www.rfc-editor.org/info/rfc6487>. <https://www.rfc-editor.org/info/rfc6487>.
[RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object [RFC6488] Lepinski, M., Chi, A., and S. Kent, "Signed Object
Template for the Resource Public Key Infrastructure Template for the Resource Public Key Infrastructure
(RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012, (RPKI)", RFC 6488, DOI 10.17487/RFC6488, February 2012,
<https://www.rfc-editor.org/info/rfc6488>. <https://www.rfc-editor.org/info/rfc6488>.
[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, <https://www.rfc-editor.org/info/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, [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,
<https://www.rfc-editor.org/info/rfc7730>. <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>.
10.2. Informative References 10.2. Informative References
[github] "RIPE NCC RPKI Validator on GitHub", [github] "RIPE NCC RPKI Validator on GitHub",
<https://github.com/RIPE-NCC/rpki-validator>. <https://github.com/RIPE-NCC/rpki-validator>.
[rsync] "Rsync home page", <https://rsync.samba.org>. [rsync] "Rsync home page", <https://rsync.samba.org>.
Authors' Addresses Authors' Addresses
Oleg Muravskiy Oleg Muravskiy
RIPE NCC RIPE NCC
Email: oleg@ripe.net Email: oleg@ripe.net
URI: https://www.ripe.net/ URI: https://www.ripe.net/
Tim Bruijnzeels Tim Bruijnzeels
NLNetLabs NLNetLabs
Email: tim@nlnetlabs.nl Email: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl/ URI: https://www.nlnetlabs.nl/
 End of changes. 30 change blocks. 
82 lines changed or deleted 81 lines changed or added

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