draft-ietf-sidr-publication-09.txt		draft-ietf-sidr-publication-10.txt
	Network Working Group S. Weiler		Network Working Group S. Weiler
	Internet-Draft Parsons		Internet-Draft W3C / MIT
	Intended status: Standards Track A. Sonalker		Intended status: Standards Track A. Sonalker
	Expires: March 25, 2017 TowerSec		Expires: July 14, 2017 TowerSec
	R. Austein		R. Austein
	Dragon Research Labs		Dragon Research Labs
	September 21, 2016		January 10, 2017
	A Publication Protocol for the Resource Public Key Infrastructure (RPKI)		A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
	draft-ietf-sidr-publication-09		draft-ietf-sidr-publication-10
	Abstract		Abstract
	This document defines a protocol for publishing Resource Public Key		This document defines a protocol for publishing Resource Public Key
	Infrastructure (RPKI) objects. Even though the RPKI will have many		Infrastructure (RPKI) objects. Even though the RPKI will have many
	participants issuing certificates and creating other objects, it is		participants issuing certificates and creating other objects, it is
	operationally useful to consolidate the publication of those objects.		operationally useful to consolidate the publication of those objects.
	This document provides the protocol for doing so.		Even in cases where a certificate issuer runs their own publication
			repository, it can be useful to run the certificate engine itself on
			a different machine from the publication repository. This document
			defines a protocol which addresses these needs.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 25, 2017.		This Internet-Draft will expire on July 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Historical Note . . . . . . . . . . . . . . . . . . . . . 4
	2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3		1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4		2. Protocol Specification . . . . . . . . . . . . . . . . . . . 5
	2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 4		2.1. Common XML Message Format . . . . . . . . . . . . . . . . 5
	2.3. Listing the repository . . . . . . . . . . . . . . . . . 5		2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 6
	2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 6		2.3. Listing the repository . . . . . . . . . . . . . . . . . 7
	2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7		2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 8
	2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 7		2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9		2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. <publish/> Query, No Existing Object . . . . . . . . . . 9		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10		3.1. <publish/> Query, No Existing Object . . . . . . . . . . 11
	3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10		3.2. <publish/> Query, Overwriting Existing Object . . . . . . 11
	3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 10		3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 12
	3.5. <report_error/> With Optional Elements . . . . . . . . . 10		3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 12
	3.6. <report_error/> Without Optional Elements . . . . . . . . 11		3.5. <report_error/> With Optional Elements . . . . . . . . . 12
	3.7. Error Handling With Multi-Element Queries . . . . . . . . 11		3.6. <report_error/> Without Optional Elements . . . . . . . . 13
	3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11		3.7. Error Handling With Multi-Element Queries . . . . . . . . 13
	3.7.2. Successful Multi-Element Response . . . . . . . . . . 12		3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 13
	3.7.3. Failure Multi-Element Response, First Error Only . . 12		3.7.2. Successful Multi-Element Response . . . . . . . . . . 14
	3.7.4. Failure Multi-Element Response, All Errors . . . . . 13		3.7.3. Failure Multi-Element Response, First Error Only . . 14
	3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 14		3.7.4. Failure Multi-Element Response, All Errors . . . . . 15
	3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 14		3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 16
	4. Operational Considerations . . . . . . . . . . . . . . . . . 14		3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 16
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		4. Operational Considerations . . . . . . . . . . . . . . . . . 16
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7.1. Normative References . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	7.2. Informative References . . . . . . . . . . . . . . . . . 17		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		8.1. Normative References . . . . . . . . . . . . . . . . . . 19
			8.2. Informative References . . . . . . . . . . . . . . . . . 19
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	1. Introduction		1. Introduction
	This document assumes a working knowledge of the Resource Public Key		This document assumes a working knowledge of the Resource Public Key
	Infrastructure (RPKI), which is intended to support improved routing		Infrastructure (RPKI), which is intended to support improved routing
	security on the Internet. [RFC6480]		security on the Internet. See [RFC6480] for an overview of the RPKI.
	In order to make participation in the RPKI easier, it is helpful to		In order to make participation in the RPKI easier, it is helpful to
	have a few consolidated repositories for RPKI objects, thus saving		have a few consolidated repositories for RPKI objects, thus saving
	every participant from the cost of maintaining a new service.		every participant from the cost of maintaining a new service.
	Similarly, relying parties using the RPKI objects will find it faster		Similarly, relying parties using the RPKI objects will find it faster
	and more reliable to retrieve the necessary set from a smaller number		and more reliable to retrieve the necessary set from a smaller number
	of repositories.		of repositories.
	These consolidated RPKI object repositories will in many cases be		These consolidated RPKI object repositories will in many cases be
	outside the administrative scope of the organization issuing a given		outside the administrative scope of the organization issuing a given
	RPKI object. In some cases, outsourcing operation of the repository		RPKI object. In some cases, outsourcing operation of the repository
	will be an explicit goal: some resource holders who strongly wish to		will be an explicit goal: some resource holders who strongly wish to
	control their own RPKI private keys may lack the resources to operate		control their own RPKI private keys may lack the resources to operate
	a 24x7 repository, or may simply not wish to do so.		a 24x7 repository, or may simply not wish to do so.
	The operator of an RPKI publication repository may well be an		The operator of an RPKI publication repository may well be an
	Internet registry which issues certificates to its customers, but it		Internet registry which issues certificates to its customers, but it
	need not be; conceptually, operation of a an RPKI publication		need not be; conceptually, operation of a an RPKI publication
	repository is separate from operation of RPKI CA.		repository is separate from operation of RPKI CA.
			Even in cases where a resource holder operates both a certificate
			engine and a publication repository, it can be useful to separate the
			two functions, as they have somewhat different operational and
			security requirements.
	This document defines an RPKI publication protocol which allows		This document defines an RPKI publication protocol which allows
	publication either within or across organizational boundaries, and		publication either within or across organizational boundaries, and
	which makes fairly minimal demands on either the CA engine or the		which makes fairly minimal demands on either the CA engine or the
	publication service.		publication service.
	1.1. Terminology		The authentication and message integrity architecture of the
			publication protocol is essentially identical to the architecture
			used in [RFC6492], because the participants in this protocol are the
			same CA engines as in RFC 6492; this allows reuse of the same
			"Business PKI" ("BPKI", see Section 1.2) infrastructure used to
			support RFC 6492. As in RCC 6492, authorization is a matter of
			external configuration: we assume that any given publication
			repository has some kind of policy controlling which certificate
			engines are allowed to publish, modify, or withdraw particular RPKI
			objects, most likely following the recommendation in [RFC6480]
			Section 4.4, the details of this policy are a private matter between
			the operator of a certificate engine and the operator of the chosen
			publication repository.
			The following diagram attempts to convey where this publication
			protocol fits into the overall data flow between the certificate
			issuers and relying parties:
			+------+ +------+ +------+
			| CA | | CA | | CA |
			+------+ +------+ +------+
			| | | Publication Protocol
			| | | Business relationship
			+-------+ | +--------+ perhaps set up by
			| | | draft-ietf-sidr-rpki-oob-setup
			+----v---v--v-----+
			| |
			| Publication |
			| Repository |
			| |
			+-----------------+ Distribution protocols
			| rsync or RRDP
			+--------------+----------------+
			| | |
			+-------v-----+ +------v------+ +------v------+
			| Relying | | Relying | | Relying |
			| Party | | Party | | Party |
			+-------------+ +-------------+ +-------------+
			The publication protocol itself is not visible to relying parties: a
			relying party sees the public interface of the publication server,
			which is an rsync or RRDP ([I-D.ietf-sidr-delta-protocol]) server.
			Operators of certificate engines and publication repositories may
			find [I-D.ietf-sidr-rpki-oob-setup] a useful tool in setting up the
			pairwise relationships between these servers, but are not required to
			use it.
			1.1. Historical Note
			This protocol started out as an informal collaboration between
			several of the early RPKI implementers, and while it was always the
			designers' intention that the resulting protocol end up on the IETF
			standards track, it took a few years to get there, because
			standardization of other pieces of the overall RPKI protocol space
			was more urgent. The standards track version of this publication
			protocol preserves the original XML namespace and protocol version
			scheme in order to maintain backwards compatibility with running code
			implemented against older versions of the specification.
			1.2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	"Publication engine" and "publication server" are used		"Publication engine" and "publication server" are used
	interchangeably to refer to the server providing the service		interchangeably to refer to the server providing the service
	described in this document.		described in this document.
	"Business Public Key Infrastructure" ("Business PKI" or "BPKI")		"Business Public Key Infrastructure" ("Business PKI" or "BPKI")
	refers to a PKI, separate from the RPKI, used to authenticate clients		refers to a PKI, separate from the RPKI, used to authenticate clients
	to the publication engine. We use the term "Business PKI" here		to the publication engine. We use the term "Business PKI" here
	because an Internet registry might already have a PKI for		because an Internet registry might already have a PKI for
	authenticating its clients and might wish to reuse that PKI for this		authenticating its clients and might wish to reuse that PKI for this
	protocol. There is, however, no requirement to reuse such a PKI.		protocol. There is, however, no requirement to reuse such a PKI.
	2. Protocol Specification		2. Protocol Specification
	The publication protocol uses XML messages wrapped in signed CMS		The publication protocol uses XML ([XML]) messages wrapped in signed
	messages, carried over HTTP transport.		CMS messages, carried over HTTP transport.
	The publication protocol uses a simple request/response interaction.		The publication protocol uses a simple request/response interaction.
	The client passes a request to the server, and the server generates a		The client passes a request to the server, and the server generates a
	corresponding response.		corresponding response.
	A message exchange commences with the client initiating an HTTP POST		A message exchange commences with the client initiating an HTTP POST
	with content type of "application/rpki-publication", with the message		with content type of "application/rpki-publication", with the message
	object as the body. The server's response will similarly be the body		object as the body. The server's response will similarly be the body
	of the response with a content type of "application/rpki-		of the response with a content type of "application/rpki-
	publication".		publication".
	The content of the POST and the server's response will be a well-		The content of the POST and the server's response will be a well-
	formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID =		formed Cryptographic Message Syntax (CMS) [RFC5652] object with OID =
	1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].		1.2.840.113549.1.7.2 as described in Section 3.1 of [RFC6492].
			The CMS signatures are used to protect the integrity of the protocol
			messages and to authenticate the client and server to each other.
			Authorization to perform particular operations is a local matter,
			perhaps determined by contractual agreements between the operators of
			any particular client-server pair, but in any case is beyond the
			scope of this specification.
	2.1. Common XML Message Format		2.1. Common XML Message Format
	The XML schema for this protocol is below in Section 2.6. The basic		The XML schema for this protocol is below in Section 2.6. The basic
	XML message format looks like this:		XML message format looks like this:
	<msg		<msg
	type="query"		type="query"
	version="4"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<!-- Zero or more PDUs -->		<!-- Zero or more PDUs -->
	skipping to change at page 4, line 44		skipping to change at page 6, line 24
	protocol. This document describes version 4.		protocol. This document describes version 4.
	type: The possible values of this attribute are "reply" and "query".		type: The possible values of this attribute are "reply" and "query".
	A query PDU may be one of three types: <publish/>, <withdraw/>, or		A query PDU may be one of three types: <publish/>, <withdraw/>, or
	<list/>.		<list/>.
	A reply PDU may be one of three types: <success/>, <list/>, or		A reply PDU may be one of three types: <success/>, <list/>, or
	<report_error/>.		<report_error/>.
	The <publish/> and <withdraw/> PDUs include a tag to facilitate bulk		The <publish/> and <withdraw/> PDUs include a "tag" attribute to
	operation.		facilitate bulk operation. When performing bulk operations, a CA
			engine will probably find it useful to specify a distinct tag value
			for each <publish/> or <withdraw/> PDU, to simplify matching an error
			with the PDU which triggered it. The tag attribute is mandatory, to
			simplify parsing, but a CA engine which has no particular use for
			tagging MAY use any syntactically legal value, including simply using
			the empty string for all tag fields.
	2.2. Publication and Withdrawal		2.2. Publication and Withdrawal
	The publication protocol uses a common message format to request		The publication protocol uses a common message format to request
	publication of any RPKI object. This format was chosen specifically		publication of any RPKI object. This format was chosen specifically
	to allow this protocol to accommodate new types of RPKI objects		to allow this protocol to accommodate new types of RPKI objects
	without needing changes to this protocol.		without needing changes to this protocol.
	Both the <publish/> and <withdraw/> PDUs have a payload of a tag and		Both the <publish/> and <withdraw/> PDUs have a payload of a tag and
	a URI. The <publish/> query also contains the DER object to be		a URI. The <publish/> query also contains the DER object to be
	published, encoded in Base64.		published, encoded in Base64.
	Both the <publish/> and <withdraw/> PDUs also have a "hash"		Both the <publish/> and <withdraw/> PDUs also have a "hash"
	attribute, which carries a hash of an existing object at the		attribute, which carries a hash of an existing object at the
	specified repository URI. For <withdraw/> PDUs, the hash is		specified repository URI, encoded as a hexadecimal string. For
	mandatory, as this operation makes no sense if there is no existing		<withdraw/> PDUs, the hash MUST be present, as this operation makes
	object to withdraw. For <publish/> PDUs, the hash MUST be present if		no sense if there is no existing object to withdraw. For <publish/>
	the publication operation is overwriting an existing object, and MUST		PDUs, the hash is MUST be present if the publication operation is
	be omitted if this publication operation is writing to a new URI		overwriting an existing object, and MUST NOT be present if this
	where no prior object exists. Presence of an object when no "hash"		publication operation is writing to a new URI where no prior object
	attribute is specified is an error, as is absence of the "hash"		exists. Presence of an object when no "hash" attribute has been
	attribute or an incorrect hash value when an object is present. Any		specified is an error, as is absence of an object or an incorrect
	such errors MUST be reported using the <report_error/> PDU.		hash value when a "hash" attribute has been specified. Any such
			errors MUST be reported using the <report_error/> PDU.
	The hash algorithm is SHA-256 [SHS], to simplify comparison of		The hash algorithm is SHA-256 [SHS], to simplify comparison of
	publication protocol hashes with RPKI manifest hashes.		publication protocol hashes with RPKI manifest hashes.
	The intent behind the "hash" attribute is to allow the client and		The intent behind the "hash" attribute is to allow the client and
	server to detect any disagreements about the effect that a <publish/>		server to detect any disagreements about the effect that a <publish/>
	or <withdraw/> PDU will have on the repository.		or <withdraw/> PDU will have on the repository.
	Note that every publish and withdraw action requires a new manifest,		Note that every publish and withdraw action requires a new manifest,
	thus every publish or withdraw action will involve at least two		thus every publish or withdraw action will involve at least two
	objects.		objects.
	Processing of a query message is handled atomically: either the		Processing of a query message is handled atomically: either the
	entire query succeeds or none of it does. When a query message		entire query succeeds or none of it does. When a query message
	contains multiple PDUs, failure of any PDU may require the server to		contains multiple PDUs, failure of any PDU may require the server to
	roll back actions triggered by earlier PDUs.		roll back actions triggered by earlier PDUs.
	When a query messages containing <publish/> and/or <withdraw/> PDUs		When a query messages containing <publish/> or <withdraw/> PDUs
	succeeds, a single <success/> reply is returned.		succeeds, the server returns a single <success/> reply.
	When a query fails, one or more <report_error/> reply PDUs are		When a query fails, the server returns one or more <report_error/>
	generated. Typically, only one <report_error/> reply is generated,		reply PDUs. Typically, a server will only generate one
	corresponding to the first query PDU that failed. Servers are		<report_error/> corresponding to the first query PDU that failed, but
	permitted to return multiple <report_error/> PDUs.		servers MAY return multiple <report_error/> PDUs at the implementor's
			discretion.
	2.3. Listing the repository		2.3. Listing the repository
	The <list/> operation allows the client to ask the server for a		The <list/> operation allows the client to ask the server for a
	complete listing of objects which the server believes the client has		complete listing of objects which the server believes the client has
	published. This is intended primarily to allow the client to recover		published. This is intended primarily to allow the client to recover
	upon detecting (probably via use of the "hash" attribute, see		upon detecting (probably via use of the "hash" attribute, see
	Section 2.2) that they have somehow lost synchronization.		Section 2.2) that they have somehow lost synchronization.
	The <list/> query consists of a single PDU. A <list/> query must be		The <list/> query consists of a single PDU. A <list/> query MUST be
	the only PDU in a query - it may not be combined with any <publish/>		the only PDU in a query - it may not be combined with any <publish/>
	or <withdraw/> queries.		or <withdraw/> queries.
	The <list/> reply consists of zero or more PDUs, one per object		The <list/> reply consists of zero or more PDUs, one per object
	published in this repository by this client, each PDU conveying the		published in this repository by this client, each PDU conveying the
	URI and hash of one published object.		URI and hash of one published object.
	2.4. Error handling		2.4. Error handling
	Errors are handled at two levels.		Errors are handled at two levels.
	skipping to change at page 7, line 45		skipping to change at page 9, line 34
	will cause a consistency problem (e.g. an object was deleted, but		will cause a consistency problem (e.g. an object was deleted, but
	the manifest was not updated). Note that a server is not required		the manifest was not updated). Note that a server is not required
	to make such checks. Indeed, it may be unwise for a server to do		to make such checks. Indeed, it may be unwise for a server to do
	so. This error code just provides a way for the server to explain		so. This error code just provides a way for the server to explain
	its (in-)action.		its (in-)action.
	other_error: A meteor fell on the server.		other_error: A meteor fell on the server.
	2.6. XML Schema		2.6. XML Schema
	The following is a RelaxNG compact form schema describing the		The following is a [RelaxNG] compact form schema describing the
	Publication Protocol.		Publication Protocol.
	# $Id: rpki-publication.rnc 3785 2016-09-21 22:21:58Z sra $		This schema is normative: in the event of a disagreement between this
			schema and the document text above, this schema is authoritative.
	# RelaxNG schema for RPKI publication protocol.		# RelaxNG schema for RPKI publication protocol.
	default namespace =		default namespace =
	"http://www.hactrn.net/uris/rpki/publication-spec/"		"http://www.hactrn.net/uris/rpki/publication-spec/"
	# This is version 4 of the protocol.		# This is version 4 of the protocol.
	version = "4"		version = "4"
	# Top level PDU is either a query or a reply.		# Top level PDU is either a query or a reply.
	skipping to change at page 9, line 41		skipping to change at page 11, line 33
	Note the authors have taken liberties with the Base64, hash, and URI		Note the authors have taken liberties with the Base64, hash, and URI
	text in these examples in the interest of making the examples fit		text in these examples in the interest of making the examples fit
	nicely into RFC text format.		nicely into RFC text format.
	3.1. <publish/> Query, No Existing Object		3.1. <publish/> Query, No Existing Object
	<msg		<msg
	type="query"		type="query"
	version="4"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<!-- body is base64(new-object) -->
	<publish		<publish
	tag="foo"		tag=""
	uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
	SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=		SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
	</publish>		</publish>
	</msg>		</msg>
	3.2. <publish/> Query, Overwriting Existing Object		3.2. <publish/> Query, Overwriting Existing Object
	<msg		<msg
	type="query"		type="query"
	version="4"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<!-- hash is hex(SHA-256(old-object)) -->
			<!-- body is base64(new-object) -->
	<publish		<publish
	hash="01a97a70ac477f06"		hash="01a97a70ac477f06"
	tag="foo"		tag="foo"
	uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
	SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=		SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
	</publish>		</publish>
	</msg>		</msg>
	3.3. <withdraw/> Query		3.3. <withdraw/> Query
	<msg		<msg
	type="query"		type="query"
	version="4"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<!-- hash is hex(SHA-256(old-object)) -->
	<withdraw		<withdraw
	hash="01a97a70ac477f06"		hash="01a97a70ac477f06"
	tag="foo"		tag="foo"
	uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/>		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/>
	</msg>		</msg>
	3.4. <success/> Reply		3.4. <success/> Reply
	<msg		<msg
	type="reply"		type="reply"
	skipping to change at page 14, line 48		skipping to change at page 16, line 48
	publication client is given its own directory one level below the top		publication client is given its own directory one level below the top
	of the rsync module, and there is no overlap between the publication		of the rsync module, and there is no overlap between the publication
	spaces used by different clients. For example:		spaces used by different clients. For example:
	rsync://example.org/rpki/Alice/		rsync://example.org/rpki/Alice/
	rsync://example.org/rpki/Bob/		rsync://example.org/rpki/Bob/
	rsync://example.org/rpki/Carol/		rsync://example.org/rpki/Carol/
	This has the advantage of being very easy for the publication		This has the advantage of being very easy for the publication
	operator to manage, but has the drawback of making it difficult for		operator to manage, but has the drawback of making it difficult for
	relying parties to fetch published objects both safely and as		relying parties to fetch published objects efficiently, particularly
	efficiently as possible.		for relying party implementations which follow the safety rule of
			never retrieving anything from a URI which didn't come directly from
			either a signed object or a trust anchor locator.
	Given that the mandatory-to-implement retrieval protocol for relying		Given that the mandatory-to-implement retrieval protocol for relying
	parties is rsync, a more efficient repository structure would be one		parties is rsync, a more efficient repository structure would be one
	which minimized the number of rsync fetches required. One such		which minimized the number of rsync fetches required. One such
	structure would be one in which the publication directories for		structure would be one in which the publication directories for
	subjects were placed underneath the publication directories of their		subjects were placed underneath the publication directories of their
	issuers: since the normal synchronization tree walk is top-down, this		issuers: since the normal synchronization tree walk is top-down, this
	can significantly reduce the total number of rsync connections		can significantly reduce the total number of rsync connections
	required to synchronize. For example:		required to synchronize. For example:
	rsync://example.org/rpki/Alice/		rsync://example.org/rpki/Alice/
	rsync://example.org/rpki/Alice/Bob/		rsync://example.org/rpki/Alice/Bob/
	rsync://example.org/rpki/Alice/Bob/Carol/		rsync://example.org/rpki/Alice/Bob/Carol/
	Preliminary measurement suggests that, in the case of large numbers		Preliminary measurement suggests that, in the case of large numbers
	of small publication directories, the time needed to set up and tear		of small publication directories, the time needed to set up and tear
	down individual rsync connections becomes significant, and that a		down individual rsync connections becomes significant, and that a
	properly optimized tree structure can reduce synchronization time by		properly optimized tree structure can reduce synchronization time by
	an order of magnitude.		an order of magnitude.
	The more complex tree structure does require careful attention to the		The more complex tree structure does require careful attention when
	"base_uri" attribute values when setting up clients. In the example		setting up clients. In the example above, assuming that Alice issues
	above, assuming that Alice issues to Bob who in turn issues to Carol,		to Bob who in turn issues to Carol, Alice has ceded control of a
	Alice has ceded control of a portion of her publication space to Bob,		portion of her publication space to Bob, who has in turn ceded a
	who has in turn ceded a portion of that to Carol, and the "base_uri"		portion of that to Carol.
	attributes in the <client/> setup messages should reflect this.
	The details of how the repository operator determines that Alice has		The details of how the repository operator determines that Alice has
	given Bob permission to nest Bob's publication directory under		given Bob permission to nest Bob's publication directory under
	Alice's is outside the scope of this protocol.		Alice's is outside the scope of this protocol.
	5. IANA Considerations		5. IANA Considerations
	IANA is asked to register the application/rpki-publication MIME media		IANA is asked to register the application/rpki-publication MIME media
	type as follows:		type as follows:
	skipping to change at page 16, line 22		skipping to change at page 18, line 22
	Interoperability considerations: None		Interoperability considerations: None
	Published specification: This document		Published specification: This document
	Applications which use this media type: HTTP		Applications which use this media type: HTTP
	Additional information:		Additional information:
	Magic number(s): None		Magic number(s): None
	File extension(s):		File extension(s):
	Macintosh File Type Code(s):		Macintosh File Type Code(s):
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Rob Austein <sra@hactrn.net>		Rob Austein <sra@hactrn.net>
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: Rob Austein <sra@hactrn.net>		Author/Change controller: IETF
	6. Security Considerations		6. Security Considerations
	The RPKI publication protocol and the data it publishes use entirely		The RPKI publication protocol and the data it publishes use entirely
	separate PKIs for authentication. The published data is		separate PKIs for authentication. The published data is
	authenticated within the RPKI, and this protocol has nothing to do		authenticated within the RPKI, and this protocol has nothing to do
	with that authentication, nor does it require that the published		with that authentication, nor does it require that the published
	objects be valid in the RPKI. The publication protocol uses a		objects be valid in the RPKI. The publication protocol uses a
	separate Business PKI (BPKI) to authenticate its messages.		separate Business PKI (BPKI) to authenticate its messages.
	Each RPKI publication protocol message is CMS-signed. Because of		Each RPKI publication protocol message is CMS-signed. Because of
	that protection at the application layer, this protocol does not		that protection at the application layer, this protocol does not
	require the use of HTTPS or other transport security mechanisms.		require the use of HTTPS or other transport security mechanisms.
	Although the hashes used in the <publish/> and <withdraw/> PDUs are		Although the hashes used in the <publish/> and <withdraw/> PDUs are
	cryptographic strength, the digest algorithm was selected for		cryptographically strong, the digest algorithm was selected for
	convenience in comparing these hashes with the hashes that appear in		convenience in comparing these hashes with the hashes that appear in
	RPKI manifests. The hashes used in the <publish/> and <withdraw/>		RPKI manifests. The hashes used in the <publish/> and <withdraw/>
	PDUs are not particularly security-sensitive, because these PDUs are		PDUs are not particularly security-sensitive, because these PDUs are
	protected by the CMS signatures.		protected by the CMS signatures.
	Compromise of a publication server, perhaps through mismanagement of		Compromise of a publication server, perhaps through mismanagement of
	BPKI keys, could lead to a denial-of-service attack on the RPKI. An		BPKI private keys, could lead to a denial-of-service attack on the
	attacker gaining access to BPKI keys could use this protocol delete		RPKI. An attacker gaining access to BPKI private keys could use this
	(withdraw) RPKI objects, leading to routing changes or failures.		protocol to delete (withdraw) RPKI objects, leading to routing
	Accordingly, as in most PKIs, good key management practices are		changes or failures. Accordingly, as in most PKIs, good key
	important.		management practices are important.
	7. References		7. Acknowledgements
	7.1. Normative References		The authors would like to thank: Geoff Huston, George Michaelson,
			Oleg Muravskiy, Paul Wouters, Randy Bush, Rob Loomans, Robert
			Kisteleki, Tim Bruijnzeels, Tom Petch, and anybody else who helped
			along the way but whose name(s) the authors have temporarily
			forgotten.
			8. References
			8.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, BCP 14, March 1997.		Requirement Levels", RFC 2119, BCP 14, March 1997.
	[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
	RFC 5652, STD 70, September 2009.		RFC 5652, STD 70, September 2009.
	[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A		[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
	Protocol for Provisioning Resource Certificates",		Protocol for Provisioning Resource Certificates",
	RFC 6492, February 2012.		RFC 6492, February 2012.
	[SHS] National Institute of Standards and Technology, "Secure		[SHS] National Institute of Standards and Technology, "Secure
	Hash Standard", FIPS PUB 180-4, March 2012,		Hash Standard", FIPS PUB 180-4, March 2012,
	<http://csrc.nist.gov/publications/fips/fips180-4/		<http://csrc.nist.gov/publications/fips/fips180-4/
	fips-180-4.pdf>.		fips-180-4.pdf>.
	7.2. Informative References		8.2. Informative References
			[I-D.ietf-sidr-delta-protocol]
			Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
			"RPKI Repository Delta Protocol", draft-ietf-sidr-delta-
			protocol-04 (work in progress), September 2016.
			[I-D.ietf-sidr-rpki-oob-setup]
			Austein, R., "An Out-Of-Band Setup Protocol For RPKI
			Production Services", draft-ietf-sidr-rpki-oob-setup-05
			(work in progress), December 2016.
			[RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November
			2002, <https://www.oasis-open.org/committees/relax-ng/
			compact-20021121.html>.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, February 2012.		Secure Internet Routing", RFC 6480, February 2012.
			[XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR
			CR-xml11-20021015, October 2002.
	Authors' Addresses		Authors' Addresses
	Samuel Weiler		Samuel Weiler
	Parsons		W3C / MIT
	Email: weiler@tislabs.com		Email: weiler@csail.mit.edu
	Anuja Sonalker		Anuja Sonalker
	TowerSec Automotive Cyber Security		TowerSec Automotive Cyber Security
	Email: asonalker@tower-sec.com		Email: asonalker@tower-sec.com
	Rob Austein		Rob Austein
	Dragon Research Labs		Dragon Research Labs
	Email: sra@hactrn.net		Email: sra@hactrn.net
End of changes. 36 change blocks.
	82 lines changed or deleted		198 lines changed or added
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/