draft-ietf-sidrops-rpki-tree-validation-03.txt		rfc8488.txt
	SIDR Operations O. Muravskiy		Internet Engineering Task Force (IETF) O. Muravskiy
	Internet-Draft RIPE NCC		Request for Comments: 8488 RIPE NCC
	Intended status: Informational T. Bruijnzeels		Category: Informational T. Bruijnzeels
	Expires: March 20, 2019 NLNetLabs		ISSN: 2070-1721 NLnet Labs
	September 16, 2018		December 2018
	RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator		RIPE NCC's Implementation of Resource Public Key Infrastructure (RPKI)
	draft-ietf-sidrops-rpki-tree-validation-03		Certificate Tree Validation
	Abstract		Abstract
	This document describes the approach to validate the content of the		This document describes an approach to validating the content of the
	RPKI certificate tree, as it is implemented in the RIPE NCC RPKI		Resource Public Key Infrastructure (RPKI) certificate tree, as it is
	Validator. This approach is independent of a particular object		implemented in the RIPE NCC RPKI Validator. This approach is
	retrieval mechanism. This allows it to be used with repositories		independent of a particular object retrieval mechanism, which allows
	available over the rsync protocol, the RPKI Repository Delta		it to be used with repositories available over the rsync protocol,
	Protocol, and repositories that use a mix of both.		the RPKI Repository Delta Protocol (RRDP), and repositories that use
			a mix of both.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This document is not an Internet Standards Track specification; it is
	provisions of BCP 78 and BCP 79.		published for informational purposes.
	Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		Internet Engineering Steering Group (IESG). Not all documents
			approved by the IESG are candidates for any level of Internet
			Standard; see Section 2 of RFC 7841.
	This Internet-Draft will expire on March 20, 2019.		Information about the current status of this document, any errata,
			and how to provide feedback on it may be obtained at
			https://www.rfc-editor.org/info/rfc8488.
	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
	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. Scope of this document . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		2. General Considerations . . . . . . . . . . . . . . . . . . . 4
	3. General Considerations . . . . . . . . . . . . . . . . . . . 4		2.1. Hash Comparisons . . . . . . . . . . . . . . . . . . . . 4
	3.1. Hash comparisons . . . . . . . . . . . . . . . . . . . . 4		2.2. Discovery of RPKI Objects Issued by a CA . . . . . . . . 5
	3.2. Discovery of RPKI objects issued by a CA . . . . . . . . 4		2.3. Manifest Entries versus Repository Content . . . . . . . 5
	3.3. Manifest entries versus repository content . . . . . . . 4		3. Top-Down Validation of a Single Trust Anchor Certificate Tree 6
	4. Top-down Validation of a Single Trust Anchor Certificate Tree 5		3.1. Fetching the Trust Anchor Certificate Using the Trust
	4.1. Fetching the Trust Anchor Certificate Using the Trust		Anchor Locator . . . . . . . . . . . . . . . . . . . . . 6
	Anchor Locator . . . . . . . . . . . . . . . . . . . . . 5		3.2. CA Certificate Validation . . . . . . . . . . . . . . . . 7
	4.2. CA Certificate Validation . . . . . . . . . . . . . . . . 6		3.2.1. Finding the Most Recent Valid Manifest and CRL . . . 8
	4.2.1. Finding the most recent valid manifest and CRL . . . 7		3.2.2. Validating Manifest Entries . . . . . . . . . . . . . 9
	4.2.2. Manifest entries validation . . . . . . . . . . . . . 8		3.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 10
	4.3. Object Store Cleanup . . . . . . . . . . . . . . . . . . 9		4. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 11
	5. Remote Objects Fetcher . . . . . . . . . . . . . . . . . . . 9		4.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 11
	5.1. Fetcher Operations . . . . . . . . . . . . . . . . . . . 9		4.1.1. Fetch Repository Objects . . . . . . . . . . . . . . 12
	5.1.1. Fetch repository objects . . . . . . . . . . . . . . 10		4.1.2. Fetch Single Repository Object . . . . . . . . . . . 12
	5.1.2. Fetch single repository object . . . . . . . . . . . 10		5. Local Object Store . . . . . . . . . . . . . . . . . . . . . 12
	6. Local Object Store . . . . . . . . . . . . . . . . . . . . . 11		5.1. Store Operations . . . . . . . . . . . . . . . . . . . . 12
	6.1. Store Operations . . . . . . . . . . . . . . . . . . . . 11		5.1.1. Store Repository Object . . . . . . . . . . . . . . . 12
	6.1.1. Store Repository Object . . . . . . . . . . . . . . . 11		5.1.2. Get Objects by Hash . . . . . . . . . . . . . . . . . 12
	6.1.2. Get objects by hash . . . . . . . . . . . . . . . . . 11		5.1.3. Get Certificate Objects by URI . . . . . . . . . . . 13
	6.1.3. Get certificate objects by URI . . . . . . . . . . . 11		5.1.4. Get Manifest Objects by AKI . . . . . . . . . . . . . 13
	6.1.4. Get manifest objects by AKI . . . . . . . . . . . . . 11		5.1.5. Delete Objects for a URI . . . . . . . . . . . . . . 13
	6.1.5. Delete objects for a URI . . . . . . . . . . . . . . 12		5.1.6. Delete Outdated Objects . . . . . . . . . . . . . . . 13
	6.1.6. Delete outdated objects . . . . . . . . . . . . . . . 12		5.1.7. Update Object's Validation Time . . . . . . . . . . . 13
	6.1.7. Update object's validation time . . . . . . . . . . . 12		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7.1. Hash Collisions . . . . . . . . . . . . . . . . . . . . . 13
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 12		7.2. Algorithm Agility . . . . . . . . . . . . . . . . . . . . 13
	9.1. Hash collisions . . . . . . . . . . . . . . . . . . . . . 12		7.3. Mismatch between the Expected and Actual Location of an
	9.2. Algorithm agility . . . . . . . . . . . . . . . . . . . . 12		Object in the Repository . . . . . . . . . . . . . . . . 14
	9.3. Mismatch between the expected and the actual location of		7.4. Manifest Content versus Publication Point Content . . . . 14
	an object in the repository . . . . . . . . . . . . . . . 13		7.5. Possible Denial of Service . . . . . . . . . . . . . . . 15
	9.4. Manifest content versus publication point content . . . . 13		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.5. Possible denial of service . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . 15
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14		8.2. Informative References . . . . . . . . . . . . . . . . . 16
	10.1. Normative References . . . . . . . . . . . . . . . . . . 14		Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
	10.2. Informative References . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Scope of this document
	This document describes how the RIPE NCC RPKI Validator version 2.23		1. Introduction
	has been implemented. Source code to this software can be found at
	[github]. The purpose of this document is to provide transparency to
	users of (and contributors to) this software tool, as well as serve
	to be subjected to scrutiny by the SIDR Operations Working Group. It
	is not intended as a document that describes a standard or best
	practices on how validation should be done in general.
	2. Introduction		This document describes how the RIPE NCC RPKI Validator version 2.25
			has been implemented. Source code for this software can be found at
			[rpki-validator]. The purpose of this document is to provide
			transparency to users of (and contributors to) this software tool.
	In order to use information published in RPKI repositories, Relying		In order to use information published in RPKI repositories, Relying
	Parties (RP) need to retrieve and validate the content of		Parties (RPs) need to retrieve and validate the content of
	certificates, certificate revocation lists (CRLs), and other RPKI		certificates, Certificate Revocation Lists (CRLs), and other RPKI
	signed objects. To validate a particular object, one must ensure		signed objects. To validate a particular object, one must ensure
	that all certificates in the certificate chain up to the Trust Anchor		that all certificates in the certificate chain up to the Trust Anchor
	(TA) are valid. Therefore the validation of a certificate tree is		(TA) are valid. Therefore, the validation of a certificate tree is
	performed top-down, starting from the TA certificate and descending		performed top-down, starting from the TA certificate and descending
	down the certificate chain, validating every encountered certificate		the certificate chain, validating every encountered certificate and
	and its products. The result of this process is a list of all		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 an RP in making routing
	routing decisions, etc.		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 the rsync protocol [rsync].
	parties are advised to keep a local copy of repository data, and		RPs are advised to keep a local copy of repository data and perform
	perform regular updates of this copy from the repository (Section 5		regular updates of this copy from the repository (see Section 5 of
	of [RFC6481]). The RPKI Repository Delta Protocol [RFC8182]		[RFC6481]). The RRDP [RFC8182] 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 of 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, the value of its Authority Key Identifier (AKI)
	or a combination of these. It also keeps track of the download and		extension, or a combination of these. It also keeps track of the
	the validation time for every object, to decide which locally stored		download and validation time for every object, to decide which
	objects are not used in the RPKI tree validation and could be		locally stored objects are not used in the RPKI tree validation and
	removed.		could be removed.
	3. General Considerations		2. General Considerations
	3.1. Hash comparisons		2.1. Hash Comparisons
	This algorithm relies on the collision resistance properties of the		This algorithm relies on the collision resistance properties of the
	file hash algorithm (defined in [RFC7935]) to compute the hash of		hash algorithm (defined in [RFC7935]) to compute the hash of
	repository objects. It assumes that any two objects for which the		repository objects. It assumes that any two objects for which the
	hash value is the same, 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 3.2.2) and when looking up
	objects in the object store (Section 6).		objects in the object store (Section 5).
	3.2. Discovery of RPKI objects issued by a CA		2.2. Discovery of RPKI Objects Issued by a CA
	There are several possible ways of discovering potential products of		There are several possible ways of discovering potential products of
	a CA certificate: one could use all objects located in a repository		a Certification Authority (CA) certificate: one could 1) use all
	directory designated as a publication point for a CA, or only objects		objects located in a repository directory designated as a publication
	mentioned on the manifest located at that publication point (see		point for a CA, 2) only use objects mentioned on the manifest located
	Section 6 of[RFC6486]), or use all known repository objects whose AKI		at that publication point (see Section 6 of [RFC6486]), or 3) use all
	extension matches the Subject Key Identifier (SKI) extension		known repository objects whose AKI extension matches the Subject Key
	(Section 4.2.1 of[RFC5280]) of a CA certificate.		Identifier (SKI) extension (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 CRL to find in an object store
	find in an object store (Section 6) a manifest and a CRL issued by a		(Section 5) a manifest and a CRL issued by a particular CA (see
	particular Certification Authority (CA) (see Section 4.2.1). It		Section 3.2.1). It further uses the hashes of the manifest's
	further uses the hashes of manifest's fileList entries (Section 4.2.1		fileList entries (Section 4.2.1 of [RFC6486]) to find other objects
	of [RFC6486]) to find other objects issued by the CA, as described in		issued by the CA, as described in Section 3.2.2.
	Section 4.2.2.
	3.3. Manifest entries versus repository content		2.3. Manifest Entries versus Repository Content
	Since the current set of RPKI standards requires use of the manifest		Since the current set of RPKI standards (see [RFC6481], [RFC6486],
	[RFC6486] to describe the content of a publication point, this		and [RFC6487]) requires use of the manifest [RFC6486] to describe the
	implementation requires strict consistency between the publication		content of a publication point, this implementation requires strict
	point content and manifest content. (This is a more stringent		consistency between the publication point content and manifest
	requirement than established in [RFC6486].) Therefore it will not		content. (This is a more stringent requirement than established in
	process objects that are found in the publication point but do not		[RFC6486].) Therefore, it will not process objects that are found in
	match any of the entries of that publication point's manifest (see		the publication point but do not match any of the entries of that
	Section 4.2.2). It will also issue warnings for all found		publication point's manifest (see Section 3.2.2). It will also issue
	mismatches, so that the responsible operators could be made aware of		warnings for all found mismatches, so that the responsible operators
	inconsistencies and fix them.		could be made aware of inconsistencies and fix them.
	4. Top-down Validation of a Single Trust Anchor Certificate Tree		3. Top-Down Validation of a Single Trust Anchor Certificate Tree
	1. The validation of a Trust Anchor (TA) certificate tree starts		When several Trust Anchors are configured, validation of their
	from its TA certificate. To retrieve the TA certificate, a Trust		corresponding certificate trees is performed concurrently and
	Anchor Locator (TAL) object is used, as described in Section 4.1.		independently from each other. For every configured Trust Anchor,
			the following steps are performed:
			1. The validation of a TA certificate tree starts from its TA
			certificate. To retrieve the TA certificate, a Trust Anchor
			Locator (TAL) object is used, as described in Section 3.1.
	2. If the TA certificate is retrieved, it is validated according to		2. If the TA certificate is retrieved, it is validated according to
	Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. Otherwise		Section 7 of [RFC6487] and Section 2.2 of [RFC7730]. Otherwise,
	the validation of certificate tree is aborted and an error is		the validation of the certificate tree is aborted and an error is
	issued.		issued.
	3. If the TA certificate is valid, then all its subordinate objects		3. If the TA certificate is valid, then all its subordinate objects
	are validated as described in Section 4.2. Otherwise the		are validated as described in Section 3.2. Otherwise, the
	validation of certificate tree is aborted and an error is issued.		validation of the certificate tree is aborted and an error is
			issued.
	4. For each repository object that was validated during this		4. For each repository object that was validated during this
	validation run, its validation timestamp is updated in the object		validation run, the validation timestamp is updated in the object
	store (see Section 6.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 4.3. This completes the validation of the TA certificate		Section 3.3. This completes the validation of the TA certificate
	tree.		tree.
	4.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 Trust Anchor Locator contains a "prefetch.uris"		1. (Optional) If the TAL contains a prefetch.uris field, pass the
	field, pass the URIs contained in that field to the fetcher (see		URIs contained in that field to the fetcher (see Section 4.1.1).
	Section 5.1.1). (This field is a non-standard addition to the		(This field is a non-standard addition to the TAL format. It
	TAL format. It helps fetching non-hierarchical rsync		helps with fetching non-hierarchical rsync repositories more
	repositories more efficiently.)		efficiently.)
	2. Extract the first TA certificate URI from the TAL's URI section		2. Extract the first TA certificate URI from the TAL's URI section
	(see Section 2.1 of [RFC7730]) and pass it to the object fetcher		(see Section 2.1 of [RFC7730]) and pass it to the object fetcher
	(Section 5.1.2). If the fetcher returns an error, repeat this		(Section 4.1.2). If the fetcher returns an error, repeat this
	step for every URI in the URI section, until no error is		step for every URI in the URI section until no error is
	encountered, or no more URIs left.		encountered or no more URIs are left.
	3. Retrieve from the object store (see Section 6.1.3) all		3. From the object store (see Section 5.1.3), retrieve all
	certificate objects, for which the URI matches the URI extracted		certificate objects for which the URI matches the URI extracted
	from the TAL in the previous step, and the public key matches the		from the TAL in the previous step and the public key matches the
	subjectPublicKeyInfo extension of the TAL (see Section 2.1 of		subjectPublicKeyInfo extension of the TAL (see Section 2.1 of
	[RFC7730]).		[RFC7730]).
	4. If no, or more than one such objects are found, issue an error		4. If no such objects are found or if more than one such objects are
	and abort certificate tree validation process with an error.		found, issue an error and abort the certificate tree validation
	Otherwise, use the single found object as the Trust Anchor		process with an error. Otherwise, use the single found object as
	certificate.		the TA certificate.
	4.2. CA Certificate Validation		3.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 [RFC8182]) SubjectInfoAccess		id-ad-rpkiNotify (Section 3.2 of [RFC8182]) instances of an
	(SIA) pointers are present in the CA certificate, use a local		accessMethod are present in the Subject Information Access
	policy to determine which pointer to use. Extract the URI from		extension of the CA certificate, use a local policy to determine
	the selected pointer and pass it to the object fetcher (that will		which pointer to use. Extract the URI from the selected pointer
	then fetch all objects available from that repository, see		and pass it to the object fetcher (that will then fetch all
	Section 5.1.1).		objects available from that repository; see Section 4.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 3.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 the
	validation process using the manifest found in the previous step.		validation process using the manifest found in the previous step.
	(This warning indicates that there is a mismatch between the		(This warning indicates that there is a mismatch between the
	expected and the actual location of an object in a repository.		expected and the actual location of an object in a repository.
	See Section 9 for the explanation of this mismatch and the		See Section 7.3 for the explanation of this mismatch and the
	decision taken.)		decision made.)
	4. Perform manifest entries discovery and validation as described in		4. Perform discovery and validation of manifest entries as described
	Section 4.2.2.		in Section 3.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:
	* 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] but with the exception of the resource
	path validation, that is performed according to		certification path validation, which is performed according to
	Section 4.2.4.4 of [RFC8360].		Section 4.2.4.4 of [RFC8360].
	(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
	the 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 an appropriate algorithm per resource certificate based
	the object identifier (OID) for the Certificate Policy found in		on the object identifier (OID) for the Certificate Policy found
	that certificate, as specified in [RFC8360].)		in that certificate, as specified in [RFC8360].)
	6. Validate all Route Origin Authorization (ROA) objects found on		6. Validate all Route Origin Authorization (ROA) objects found on
	the manifest, using the CRL object found on the manifest,		the manifest using the CRL object found on the manifest,
	according to Section 4 of [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, recursively,
	recursively, provided that this CA certificate (identified by its		provided that this CA certificate (identified by its SKI) has not
	SKI) has not yet been validated during current tree validation		yet been validated during current tree validation run.
	run.
	4.2.1. Finding the most recent valid manifest and CRL		3.2.1. Finding the Most Recent Valid Manifest and CRL
	1. Fetch from the store (see Section 6.1.4) all objects of type		To find the most recent issued manifest and CRL objects of a
	manifest, whose certificate's AKI extension matches the SKI of		particular CA certificate, the following steps are performed:
	the current CA certificate. If no such objects are found, stop
			1. From the store (see Section 5.1.4), fetch all objects of type
			manifest whose certificate's AKI extension matches the SKI of the
			current CA certificate. If no such objects are found, stop
	processing the current CA certificate and issue an error.		processing the current CA certificate and issue an error.
	2. Find among found objects the manifest object with the highest		2. Among found objects, find the manifest object with the highest
	manifestNumber field (Section 4.2.1 of [RFC6486]), for which all		manifestNumber field (Section 4.2.1 of [RFC6486]) for which all
	following conditions are met:		following conditions are met:
	* 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, the hash of which		contains exactly one object of type CRL, the hash of which
	matches the hash of the entry.		matches the hash of the entry.
	* The manifest's certificate AKI equals the above CRL's AKI.		* The manifest's certificate AKI equals the above CRL's AKI.
	* 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].
	* 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], and its EE certificates is not in the CRL found		[RFC6486], and its EE certificate is not in the CRL found
	above.		above.
	3. If there is an object that matches above criteria, consider this		3. If there is an object that matches the above criteria, consider
	object to be the valid manifest, and the CRL found at the		this object to be the valid manifest, and consider the CRL found
	previous step - the valid CRL for the current CA certificate's		at the previous step to be the valid CRL for the current CA
	publication point.		certificate's publication point.
	4. Report an error for every other manifest with a number higher		4. Report an error for every other manifest with a number higher
	than the number of the valid manifest.		than the number of the valid manifest.
	4.2.2. Manifest entries validation		3.2.2. Validating Manifest Entries
	For every entry in the manifest object:		For every entry in the manifest object:
	1. 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.
	2. Get all objects from the store whose hash attribute equals		2. Get all objects from the store whose hash attribute equals the
	entry's hash (see Section 6.1.2).		entry's hash (see Section 5.1.2).
	3. If no such objects are found, issue an error for this manifest		3. If no such objects are found, issue an error for this manifest
	entry and progress to the next entry. This case indicates that		entry and progress to the next entry. This case indicates that
	the repository does not have an object at the location listed in		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		the manifest or that the object's hash does not match the hash
	listed in the manifest.		listed in the manifest.
	4. 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.		manifest entry.
	* For every object with a non-matching URI issue a warning.		* For every object with a non-matching URI, issue a warning.
	This case indicates that the object from the manifest entry is		This case indicates that the object from the manifest entry is
	(also) found at a different location in a (possibly different)		(also) found at a different location in a (possibly different)
	repository.		repository.
	* 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 3.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 whose URI does not. See
	Section 9.3 for additional information.		Section 7.3 for additional information.
	4.3. Object Store Cleanup		3.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 5.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 whose content's hash does not match the hash of any
	the store objects that were replaced in the repository by their		of the encountered objects. This removes from the store objects
	newer versions with the same URIs.		that were replaced in the repository by their newer versions with
			the same URIs.
	2. Remove from the store all objects that were last encountered		2. Remove from the store all objects that were last encountered
	during validation a long time ago (as specified by the local		during validation a long time ago (as specified by the local
	policy). This removes objects that do not appear on any valid		policy). This removes objects that do not appear on any valid
	manifest anymore (but possibly are still published in a		manifest anymore (but possibly are still published in a
	repository).		repository).
	3. Remove from the store all objects that were downloaded recently		3. Remove from the store all objects that were downloaded recently
	(as specified by the local policy), but have never been used in		(as specified by the local policy) but that have never been used
	the validation process. This removes objects that have never		in the validation process. This removes objects that have never
	appeared on any valid manifest.		appeared on any valid manifest.
	Shortening the time interval used in step 2 will free more disk space		Shortening the time interval used in step 2 will free more disk space
	used by the store, at the expense of downloading removed objects		used by the store, at the expense of downloading removed objects
	again if they are still published in the repository.		again if they are still published in the repository.
	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 unused repository objects. However, it will also extend
	created massively by mistake or by an adversary, will fill up local		the interval at which unused objects are removed. This creates a
	disk space, if they are not cleaned up promptly.		risk that such objects will fill up all available disk space if a
			large enough amount of such objects is published in the repository
			(either by mistake or with a malicious intent).
	5. Remote Objects Fetcher		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 the rsync
	protocol ([rsync]), or RPKI Repository Delta Protocol (RRDP)		protocol [rsync] or RRDP [RFC8182].
	([RFC8182]).
	5.1. Fetcher Operations		4.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		4.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,
	points to the repository's notification file.		it points to the repository's notification file.
	The fetcher performs following steps:		The fetcher follows these steps:
	1. If data associated with the URI has been downloaded recently (as		1. If data associated with the URI has been downloaded recently (as
	specified by the local policy), skip following steps.		specified by the local policy), skip the following steps.
	2. Download remote objects using the URI provided (for an rsync		2. Download remote objects using the URI provided (for an rsync
	repository use recursive mode). If the URI contains schema		repository, use recursive mode). If the URI contains the "https"
	"https" and download has failed, issue a warning, replace "https"		schema and download has failed, issue a warning, replace the
	schema in the URI by "http", and try to download objects again,		"https" schema in the URI with "http", and try to download
	using the resulting URI.		objects again using the resulting URI.
	3. If remote objects can not be downloaded, issue an error and skip		3. If remote objects cannot be downloaded, issue an error and skip
	following steps.		the following steps.
	4. Perform syntactic verification of fetched objects. The type of		4. Perform syntactic verification of fetched objects. The type of
	every object (certificate, manifest, CRL, ROA, or Ghostbusters		every object (certificate, manifest, CRL, ROA, or Ghostbusters
	record), is determined based on the object's filename extension		Record) is determined based on the object's filename extension
	(.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of		(.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of
	the object is described in Section 4 of [RFC6487] for resource		the object is described in Section 4 of [RFC6487] for resource
	certificates, step 1 of Section 3 of [RFC6488] for signed		certificates, step 1 of Section 3 of [RFC6488] for signed
	objects, and specifically, Section 4 of [RFC6486] for manifests,		objects, Section 4 of [RFC6486] for manifests, [RFC5280] for
	[RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and		CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493]
	Section 5 of [RFC6493] for Ghostbusters records.		for Ghostbusters Records.
	5. Put every downloaded and syntactically correct object in the		5. Put every downloaded and syntactically correct object in the
	object store (Section 6.1.1).		object store (Section 5.1.1).
	The time interval used in the step 1 should be chosen based on the		The time interval used in step 1 should be chosen based on the
	acceptable delay in receiving repository updates.		acceptable delay in receiving repository updates.
	5.1.2. Fetch single repository object		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 repository.		object in a repository.
	The fetcher performs following operations:		The fetcher follows these steps:
	1. Download remote object using the URI provided. If the URI		1. Download a remote object using the URI provided. If the URI
	contains "https" schema and download failed, issue a warning,		contains the "https" schema and download failed, issue a warning,
	replace "https" schema in the URI by "http", and try to download		replace the "https" schema in the URI with "http", and try to
	the object using the resulting URI.		download the object using the resulting URI.
	2. If the remote object can not be downloaded, issue an error and		2. If the remote object cannot be downloaded, issue an error and
	skip following steps.		skip the following steps.
	3. Perform syntactic verification of fetched object. The type of		3. Perform syntactic verification of the fetched object. The type
	object (certificate, manifest, CRL, ROA, or Ghostbusters record),		of object (certificate, manifest, CRL, ROA, or Ghostbusters
	is determined based on the object's filename extension (.cer,		Record) is determined based on the object's filename extension
	.mft, .crl, .roa, and .gbr, respectively). The syntax of the		(.cer, .mft, .crl, .roa, and .gbr, respectively). The syntax of
	object is described in Section 4 of [RFC6487] for resource		the object is described in Section 4 of [RFC6487] for resource
	certificates, step 1 of Section 3 of [RFC6488] for signed		certificates, step 1 of Section 3 of [RFC6488] for signed
	objects, and specifically, Section 4 of [RFC6486] for manifests,		objects, Section 4 of [RFC6486] for manifests, [RFC5280] for
	[RFC5280] for CRLs, Section 3 of [RFC6482] for ROAs, and		CRLs, Section 3 of [RFC6482] for ROAs, and Section 5 of [RFC6493]
	Section 5 of [RFC6493] for Ghostbusters records.		for Ghostbusters Records.
	4. If the downloaded object is not syntactically correct, issue an		4. If the downloaded object is not syntactically correct, issue an
	error and skip further steps.		error and skip further steps.
	5. Delete all objects from the object store (Section 6.1.5) whose		5. Delete all objects from the object store (Section 5.1.5) whose
	URI matches the URI given.		URI matches the URI given.
	6. Put the downloaded object in the object store (Section 6.1.1).		6. Put the downloaded object in the object store (Section 5.1.1).
	6. Local Object Store		5. Local Object Store
	6.1. Store Operations		5.1. Store Operations
	6.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 the given object in the store if there is no record with the same
	AKI, if there is no record with the same hash and URI fields. Note		hash and URI fields. Note that in the (unlikely) event of hash
	that in the (unlikely) event of hash collision the given object will		collision, the given object will not replace the object in the store.
	not replace the object in the store.
	6.1.2. Get objects by hash		5.1.2. 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.
	6.1.3. 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.
	6.1.4. 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.
	6.1.5. Delete objects for a 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 a matching URI
	attribute.		attribute.
	6.1.6. 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 a matching URI whose hash attribute is not in the given list of
	hashes.		hashes.
	6.1.7. 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.
	7. Acknowledgements		6. IANA Considerations
	This document describes the algorithm as it is implemented by the
	software development team at the RIPE NCC, which included over time:
	Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da
	Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo
	Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn
	Visinescu. The authors would also like to acknowledge contributions
	by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.
	8. IANA Considerations
	This document has no actions for IANA.		This document has no IANA actions.
	9. Security Considerations		7. Security Considerations
	9.1. Hash collisions		7.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 [RFC7935]). It considers objects with same		algorithm specified in [RFC7935]). It considers objects with same
	hash values as identical.		hash values to be identical.
	9.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.
	9.3. Mismatch between the expected and the actual location of an object		7.3. Mismatch between the Expected and Actual Location of an Object in
	in the repository		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 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, has either a different file name, or is		hash listed in the manifest either has a different filename or is
	located at a different publication point in a repository.		located at a different publication point in a repository.
	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 AKI extension that contains
	extension that contains the key identifier of their issuing CA		the key identifier of their issuing CA certificate. Therefore, it is
	certificate. Therefore it is always possible to perform an RPKI		always possible to perform an RPKI validation of the object whose
	validation of the object whose expected location does not match its		expected location does not match its actual location, provided that
	actual location, provided that the certificate that matches the AKI		the certificate that matches the AKI of the object in question is
	of the object in question is known to the system that performs		known to the system that performs validation.
	validation.
	In case of a mismatch described above this implementation will not		In the case of a mismatch as described above, this implementation
	exclude an object from further validation merely because its actual		will not exclude an object from further validation merely because its
	location or file name does not match the expected location or file		actual location or filename does not match the expected location or
	name. This decision was chosen because the actual location of a file		filename. This decision was made because the actual location of a
	in a repository is taken from the repository retrieval mechanism,		file in a repository is taken from the repository retrieval
	which, in case of an rsync repository, does not provide any		mechanism, which, in the case of an rsync repository, does not
	cryptographic security, and in case of an RRDP repository, provides		provide any cryptographic security, and in the case of an RRDP
	only a transport layer security, with the fallback to unsecured		repository, provides only a transport-layer security with the
	transport. On the other hand, the manifest is an RPKI signed object,		fallback to unsecured transport. On the other hand, the manifest is
	and its content could be verified in the context of the RPKI		an RPKI signed object, and its content could be verified in the
	validation.		context of the RPKI validation.
	9.4. Manifest content versus publication point content		7.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
	by the same CA as the manifest. (This RP behavior is allowed, but		the same CA as the manifest. (This RP behavior is allowed, but not
	not required, by [RFC6486].)		required, by [RFC6486].)
	9.5. Possible denial of service		7.5. Possible Denial of Service
	The store cleanup procedure described in Section 4.3 tries to		The store cleanup procedure described in Section 3.3 tries to
	minimise removal and subsequent re-fetch of objects that are		minimize 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 (see Section 5.1.1)		fetch and store those objects in the object store (see Section 4.1.1)
	before they are validated and discarded, leading to an out-of-memory		before they are validated and discarded, leading to out-of-memory or
	or out-of-disk-space conditions, and, subsequently, a denial of		out-of-disk-space conditions and, subsequently, a denial of service.
	service.
	10. References		8. References
	10.1. Normative References		8.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,
	<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,
	skipping to change at page 15, line 40 ¶		skipping to change at page 16, line 35 ¶
	"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,		"The RPKI Repository Delta Protocol (RRDP)", RFC 8182,
	DOI 10.17487/RFC8182, July 2017,		DOI 10.17487/RFC8182, July 2017,
	<https://www.rfc-editor.org/info/rfc8182>.		<https://www.rfc-editor.org/info/rfc8182>.
	[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>.
	10.2. Informative References		8.2. Informative References
	[github] "RIPE NCC RPKI Validator on GitHub",		[rpki-validator]
			"RIPE-NCC/rpki-validator source code",
	<https://github.com/RIPE-NCC/rpki-validator>.		<https://github.com/RIPE-NCC/rpki-validator>.
	[rsync] "Rsync home page", <https://rsync.samba.org>.		[rsync] "rsync", October 2018, <https://rsync.samba.org>.
			Acknowledgements
			This document describes the algorithm as it is implemented by the
			software development team at the RIPE NCC, which, over time, included
			Mikhail Puzanov, Erik Rozendaal, Miklos Juhasz, Misja Alma, Thiago da
			Cruz Pereira, Yannis Gonianakis, Andrew Snare, Varesh Tapadia, Paolo
			Milani, Thies Edeling, Hans Westerbeek, Rudi Angela, and Constantijn
			Visinescu. The authors would also like to acknowledge contributions
			by Carlos Martinez, Andy Newton, Rob Austein, and Stephen Kent.
	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		NLnet Labs
	Email: tim@nlnetlabs.nl		Email: tim@nlnetlabs.nl
	URI: https://www.nlnetlabs.nl/		URI: https://www.nlnetlabs.nl/
End of changes. 133 change blocks.
	335 lines changed or deleted		338 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/