rfc8488.txt   test8488.v2v3.txt 
Internet Engineering Task Force (IETF) O. Muravskiy Internet Engineering Task Force (IETF) O. Muravskiy
Request for Comments: 8488 RIPE NCC Request for Comments: 8488 RIPE NCC
Category: Informational T. Bruijnzeels Category: Informational T. Bruijnzeels
ISSN: 2070-1721 NLnet Labs ISSN: 2070-1721 NLNetLabs
December 2018 December 2018
RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI) RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI)
Certificate Tree Validation Certificate Tree Validation
Abstract Abstract
This document describes an approach to validating the content of the This document describes an approach to validating the content of the
Resource Public Key Infrastructure (RPKI) certificate tree, as it is Resource Public Key Infrastructure (RPKI) certificate tree, as it is
implemented in the RIPE NCC RPKI Validator. This approach is implemented in the RIPE NCC RPKI Validator. This approach is
skipping to change at page 2, line 12 skipping to change at line 44
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8488. https://www.rfc-editor.org/info/rfc8488.
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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
2. General Considerations . . . . . . . . . . . . . . . . . . . 4 2. General Considerations
2.1. Hash Comparisons . . . . . . . . . . . . . . . . . . . . 4 2.1. Hash Comparisons
2.2. Discovery of RPKI Objects Issued by a CA . . . . . . . . 5 2.2. Discovery of RPKI Objects Issued by a CA
2.3. Manifest Entries versus Repository Content . . . . . . . 5 2.3. Manifest Entries versus Repository Content
3. Top-Down Validation of a Single Trust Anchor Certificate Tree 6 3. Top-Down Validation of a Single Trust Anchor Certificate Tree
3.1. Fetching the Trust Anchor Certificate Using the Trust 3.1. Fetching the Trust Anchor Certificate Using the Trust
Anchor Locator . . . . . . . . . . . . . . . . . . . . . 6 Anchor Locator
3.2. CA Certificate Validation . . . . . . . . . . . . . . . . 7 3.2. CA Certificate Validation
3.2.1. Finding the Most Recent Valid Manifest and CRL . . . 8 3.2.1. Finding the Most Recent Valid Manifest and
3.2.2. Validating Manifest Entries . . . . . . . . . . . . . 9 CRL
3.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 10 3.2.2. Validating Manifest Entries
4. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 11 3.3. Object Store Cleanup
4.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 11 4. Remote Objects Fetcher
4.1.1. Fetch Repository Objects . . . . . . . . . . . . . . 12 4.1. Fetcher Operations
4.1.2. Fetch Single Repository Object . . . . . . . . . . . 12 4.1.1. Fetch Repository Objects
5. Local Object Store . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. Fetch Single Repository Object
5.1. Store Operations . . . . . . . . . . . . . . . . . . . . 12 5. Local Object Store
5.1.1. Store Repository Object . . . . . . . . . . . . . . . 12 5.1. Store Operations
5.1.2. Get Objects by Hash . . . . . . . . . . . . . . . . . 12 5.1.1. Store Repository Object
5.1.3. Get Certificate Objects by URI . . . . . . . . . . . 13 5.1.2. Get Objects by Hash
5.1.4. Get Manifest Objects by AKI . . . . . . . . . . . . . 13 5.1.3. Get Certificate Objects by URI
5.1.5. Delete Objects for a URI . . . . . . . . . . . . . . 13 5.1.4. Get Manifest Objects by AKI
5.1.6. Delete Outdated Objects . . . . . . . . . . . . . . . 13 5.1.5. Delete Objects for a URI
5.1.7. Update Object's Validation Time . . . . . . . . . . . 13 5.1.6. Delete Outdated Objects
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5.1.7. Update Object's Validation Time
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations
7.1. Hash Collisions . . . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations
7.2. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 13 7.1. Hash Collisions
7.3. Mismatch between the Expected and Actual Location of an 7.2. Algorithm Agility
Object in the Repository . . . . . . . . . . . . . . . . 14 7.3. Mismatch between the Expected and Actual Location of
7.4. Manifest Content versus Publication Point Content . . . . 14 an Object in the Repository
7.5. Possible Denial of Service . . . . . . . . . . . . . . . 15 7.4. Manifest Content versus Publication Point Content
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Possible Denial of Service
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 8. References
8.2. Informative References . . . . . . . . . . . . . . . . . 16 8.1. Normative References
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Informative References
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgements
Authors' Addresses
1. Introduction 1. Introduction
This document describes how the RIPE NCC RPKI Validator version 2.25 This document describes how the RIPE NCC RPKI Validator version 2.25
has been implemented. Source code for this software can be found at has been implemented. Source code for this software can be found at
[rpki-validator]. The purpose of this document is to provide [rpki-validator]. The purpose of this document is to provide
transparency to users of (and contributors to) this software tool. transparency to users of (and contributors to) this software tool.
In order to use information published in RPKI repositories, Relying In order to use information published in RPKI repositories, Relying
Parties (RPs) need to retrieve and validate the content of Parties (RPs) need to retrieve and validate the content of
skipping to change at page 6, line 34 skipping to change at line 213
issued. issued.
4. For each repository object that was validated during this 4. For each repository object that was validated during this
validation run, the validation timestamp is updated in the object validation run, the validation timestamp is updated in the object
store (see Section 5.1.7). store (see Section 5.1.7).
5. Outdated objects are removed from the store as described in 5. Outdated objects are removed from the store as described in
Section 3.3. This completes the validation of the TA certificate Section 3.3. This completes the validation of the TA certificate
tree. tree.
3.1. Fetching the Trust Anchor Certificate Using the Trust Anchor 3.1. Fetching the Trust Anchor Certificate Using the Trust Anchor Locator
Locator
The following steps are performed in order to fetch a Trust Anchor The following steps are performed in order to fetch a Trust Anchor
certificate: certificate:
1. (Optional) If the TAL contains a prefetch.uris field, pass the 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). 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 (This field is a non-standard addition to the TAL format. It
helps with fetching non-hierarchical rsync repositories more helps with fetching non-hierarchical rsync repositories more
efficiently.) efficiently.)
skipping to change at page 14, line 5 skipping to change at line 551
hashes of repository objects (calculated using the file hash hashes of repository objects (calculated using the file hash
algorithm specified in [RFC7935]). It considers objects with same algorithm specified in [RFC7935]). It considers objects with same
hash values to be identical. hash values to be identical.
7.2. Algorithm Agility 7.2. Algorithm Agility
This implementation only supports hash algorithms and key sizes This implementation only supports hash algorithms and key sizes
specified in [RFC7935]. Algorithm agility described in [RFC6916] is specified in [RFC7935]. Algorithm agility described in [RFC6916] is
not supported. not supported.
7.3. Mismatch between the Expected and Actual Location of an Object in 7.3. Mismatch between the Expected and Actual Location of an Object in the
the Repository 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 filenames and enumerates all other issued objects, listing their filenames 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
hash listed in the manifest either has a different filename or is hash listed in the manifest either has a different filename or is
skipping to change at page 16, line 38 skipping to change at line 678
[RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T., [RFC8360] Huston, G., Michaelson, G., Martinez, C., Bruijnzeels, T.,
Newton, A., and D. Shaw, "Resource Public Key Newton, A., and D. Shaw, "Resource Public Key
Infrastructure (RPKI) Validation Reconsidered", RFC 8360, Infrastructure (RPKI) Validation Reconsidered", RFC 8360,
DOI 10.17487/RFC8360, April 2018, DOI 10.17487/RFC8360, April 2018,
<https://www.rfc-editor.org/info/rfc8360>. <https://www.rfc-editor.org/info/rfc8360>.
8.2. Informative References 8.2. Informative References
[rpki-validator] [rpki-validator]
"RIPE-NCC/rpki-validator source code", "RIPE-NCC/rpki-validator source code", January 2019,
<https://github.com/RIPE-NCC/rpki-validator>. <https://github.com/RIPE-NCC/rpki-validator>.
[rsync] "rsync", October 2018, <https://rsync.samba.org>. [rsync] "rsync", October 2018, <https://rsync.samba.org>.
Acknowledgements 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, which, over time, included software development team at the RIPE NCC, which, over time, included
Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da
Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo
Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn
Visinescu. The authors would also like to acknowledge contributions Visinescu. The authors would also like to acknowledge contributions
by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent. by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.
Authors' Addresses Authors' Addresses
Oleg Muravskiy
RIPE NCC
Email: oleg@ripe.net Email: oleg@ripe.net
URI: https://www.ripe.net/ URI: https://www.ripe.net/
Tim Bruijnzeels
NLnet Labs
Email: tim@nlnetlabs.nl Email: tim@nlnetlabs.nl
URI: https://www.nlnetlabs.nl/ URI: https://www.nlnetlabs.nl/
 End of changes. 8 change blocks. 
51 lines changed or deleted 45 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/

mirror server hosted at Truenetwork, Russian Federation.