Diff: rfc8488.txt - test8488.v2v3.txt

	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/