draft-ietf-sidr-publication-07.txt		draft-ietf-sidr-publication-08.txt
	Network Working Group S. Weiler		Network Working Group S. Weiler
	Internet-Draft Parsons		Internet-Draft Parsons
	Intended status: Standards Track A. Sonalker		Intended status: Standards Track A. Sonalker
	Expires: March 28, 2016 Battelle Memorial Institute		Expires: September 22, 2016 TowerSec
	R. Austein		R. Austein
	Dragon Research Labs		Dragon Research Labs
	September 25, 2015		March 21, 2016
	A Publication Protocol for the Resource Public Key Infrastructure (RPKI)		A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
	draft-ietf-sidr-publication-07		draft-ietf-sidr-publication-08
	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.		This document provides the protocol for doing so.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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 28, 2016.		This Internet-Draft will expire on September 22, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2016 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3		2. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
	2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4		2.1. Common XML Message Format . . . . . . . . . . . . . . . . 4
	2.2. General Operation . . . . . . . . . . . . . . . . . . . . 4		2.2. Publication and Withdrawal . . . . . . . . . . . . . . . 4
	2.3. Publication and Withdrawal . . . . . . . . . . . . . . . 5		2.3. Listing the repository . . . . . . . . . . . . . . . . . 5
	2.4. Listing the repository . . . . . . . . . . . . . . . . . 5		2.4. Error handling . . . . . . . . . . . . . . . . . . . . . 6
	2.5. Error handling . . . . . . . . . . . . . . . . . . . . . 6		2.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7
	2.6. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 7		2.6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 7
	2.7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . 8
	3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.1. <publish/> Query, No Existing Object . . . . . . . . . . 10		3.1. <publish/> Query, No Existing Object . . . . . . . . . . 9
	3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10		3.2. <publish/> Query, Overwriting Existing Object . . . . . . 10
	3.3. <publish/> Reply . . . . . . . . . . . . . . . . . . . . 10		3.3. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10
	3.4. <withdraw/> Query . . . . . . . . . . . . . . . . . . . . 10		3.4. <success/> Reply . . . . . . . . . . . . . . . . . . . . 10
	3.5. <withdraw/> Reply . . . . . . . . . . . . . . . . . . . . 11		3.5. <report_error/> With Optional Elements . . . . . . . . . 10
	3.6. <report_error/> With Optional Elements . . . . . . . . . 11		3.6. <report_error/> Without Optional Elements . . . . . . . . 11
	3.7. <report_error/> Without Optional Elements . . . . . . . . 11		3.7. Error Handling With Multi-Element Queries . . . . . . . . 11
	3.8. Error Handling With Multi-Element Queries . . . . . . . . 11		3.7.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11
	3.8.1. Multi-Element Query . . . . . . . . . . . . . . . . . 11		3.7.2. Successful Multi-Element Response . . . . . . . . . . 12
	3.8.2. Successful Multi-Element Response . . . . . . . . . . 12		3.7.3. Failure Multi-Element Response, First Error Only . . 12
	3.8.3. Failure Multi-Element Response . . . . . . . . . . . 13		3.7.4. Failure Multi-Element Response, All Errors . . . . . 13
			3.8. <list/> Query . . . . . . . . . . . . . . . . . . . . . . 14
			3.9. <list/> Reply . . . . . . . . . . . . . . . . . . . . . . 14
	4. Operational Considerations . . . . . . . . . . . . . . . . . 14		4. Operational Considerations . . . . . . . . . . . . . . . . . 14
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		7. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.1. Normative References . . . . . . . . . . . . . . . . . . 17		7.1. Normative References . . . . . . . . . . . . . . . . . . 17
	7.2. Informative References . . . . . . . . . . . . . . . . . 17		7.2. Informative References . . . . . . . . . . . . . . . . . 17
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	skipping to change at page 3, line 35		skipping to change at page 3, line 37
	"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 messages wrapped in signed CMS
	messages, carried over HTTP transport.		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
	skipping to change at page 4, line 11		skipping to change at page 4, line 14
	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].
	2.1. Common XML Message Format		2.1. Common XML Message Format
	The XML schema for this protocol is below in Section 2.7. 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="3"		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 -->
	</msg>		</msg>
	<msg		<msg
	type="reply"		type="reply"
	version="3"		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 -->
	</msg>		</msg>
	Common attributes:		Common attributes:
	version: The value of this attribute is the version of this		version: The value of this attribute is the version of this
	protocol. This document describes version 3.		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 four types: <publish/>, <withdraw/>,		A reply PDU may be one of three types: <success/>, <list/>, or
	<list/>, or <report_error/>.		<report_error/>.
	Each of these PDUs may include an optional tag to facilitate bulk
	operation. If a tag is set in a query PDU, the corresponding
	reply(s) or error(s) MUST have the tag attribute set to the same
	value.
	2.2. General Operation
	Processing of a query message is handled atomically: either the		The <publish/> and <withdraw/> PDUs include a tag to facilitate bulk
	entire query succeeds or none of it does. When a query message		operation.
	contains multiple PDUs, failure of any PDU may require the server to
	roll back actions triggered by earlier PDUs.
	2.3. 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 an		Both the <publish/> and <withdraw/> PDUs have a payload of a tag and
	optional tag and a URI. The <publish/> query also contains the DER		a URI. The <publish/> query also contains the DER object to be
	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. For <withdraw/> PDUs, the hash is
	mandatory, as this operation makes no sense if there is no existing		mandatory, as this operation makes no sense if there is no existing
	object to withdraw. For <publish/> PDUs, the hash MUST be present if		object to withdraw. For <publish/> PDUs, the hash MUST be present if
	the publication operation is overwriting an existing object, and MUST		the publication operation is overwriting an existing object, and MUST
	be omitted if this publication operation is writing to a new URI		be omitted if this publication operation is writing to a new URI
	where no prior object exists. Presence of an object when no hash		where no prior object exists. Presence of an object when no "hash"
	attribute is specified is an error, as is absence of the hash		attribute is specified is an error, as is absence of the "hash"
	attribute or an incorrect hash value when an object is present. Any		attribute or an incorrect hash value when an object is present. Any
	such errors MUST be reported using the <report_error/> PDU.		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.
	2.4. Listing the repository		Processing of a query message is handled atomically: either the
			entire query succeeds or none of it does. When a query message
			contains multiple PDUs, failure of any PDU may require the server to
			roll back actions triggered by earlier PDUs.
			When a query messages containing <publish/> and/or <withdraw/> PDUs
			succeeds, a single <success/> reply is returned.
			When a query fails, one or more <report_error/> reply PDUs are
			generated. Typically, only one <report_error/> reply is generated,
			corresponding to the first query PDU that failed. Servers are
			permitted to return multiple <report_error/> PDUs.
			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.3) that they have somehow lost synchronization.		Section 2.2) that they have somehow lost synchronization.
	The <list/> query consists of a single PDU.		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/>
			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.5. Error handling		2.4. Error handling
	Errors are handled at two levels.		Errors are handled at two levels.
	Errors that make it impossible to decode a query or encode a response		Errors that make it impossible to decode a query or encode a response
	are handled at the HTTP layer. 4xx and 5xx HTTP response codes		are handled at the HTTP layer. 4xx and 5xx HTTP response codes
	indicate that something bad happened.		indicate that something bad happened.
	In all other cases, errors result in an XML <report_error/> PDU which		In all other cases, errors result in an XML <report_error/> PDU.
	takes the place of the expected protocol response PDU. Like the rest		Like the rest of this protocol, <report_error/> PDUs are CMS-signed
	of this protocol, <report_error/> PDUs are CMS-signed XML messages		XML messages and thus can be archived to provide an audit trail.
	and thus can be archived to provide an audit trail.
	<report_error/> PDUs only appear in replies, never in queries.		<report_error/> PDUs only appear in replies, never in queries.
	Like all other reply PDUs, if a "tag" attribute was set on the query		The "tag" attribute of the <report_error/> PDU associated with a
	that generated the error, the <report_error/> PDU MUST have its tag		<publish/> or <withdraw/> PDU MUST be set to the same value as the
	attribute set to the same value.		"tag" attribute in the PDU which generated the error. A client can
			use the "tag" attribute to determine which PDU caused processing of
			an update to fail.
	The error itself is conveyed in the error_code attribute. The value		The error itself is conveyed in the "error_code" attribute. The
	of this attribute is a token indicating the specific error that		value of this attribute is a token indicating the specific error that
	occurred.		occurred.
	The body of the <report_error/> element contains two sub-elements:		The body of the <report_error/> element contains two sub-elements:
	1. An optional text element <error_text/>, which if present,		1. An optional text element <error_text/>, which if present,
	contains a text string with debugging information intended for		contains a text string with debugging information intended for
	human consumption.		human consumption.
	2. An optional element <failed_pdu/>, which, if present, contains a		2. An optional element <failed_pdu/>, which, if present, contains a
	verbatim copy of the query PDU whose failure triggered the		verbatim copy of the query PDU whose failure triggered the
	<report_error/> PDU. The quoted element must be syntactically		<report_error/> PDU. The quoted element must be syntactically
	valid.		valid.
	The position of a <report_error/> element in a reply corresponds to		See Section 3.7 for examples of a multi-element query and responses.
	the point in processing the query message where the error occurred.
	In the simple case of a query message containing only a single
	element, the <report_error/> element will be the only element in the
	reply. If, however, the query message contains more than one
	element, the <report_error/> element may be preceeded by normal
	responses indicating operations that would have succeeded.
	There are several ways that a client can match up elements in a
	response message with the corresponding elements in the query
	message:
	o For a one-element query, this is trivial.
	o For multi-element queries, the simplest way of matching resposes
	uses the optional tag attribute. The protocol requires tags from
	query elements to be copied into reply elements, so simply giving
	each query element a unique tag will suffice.
	o If for some reason the client implementation is not able or
	willing to use unique tags within a multi-element query message,
	the client can still match queries to responses by counting
	elements in the reply message. This approach is not recommended.
	See Section 3.8 for examples of a multi-element query and responses.
	2.6. Error Codes		2.5. Error Codes
	These are the defined error codes as well as some discussion of each.		These are the defined error codes as well as some discussion of each.
	Text similar to these descriptions may be sent in an <error_text/>		Text similar to these descriptions may be sent in an <error_text/>
	element to help explain the error encountered.		element to help explain the error encountered.
			xml_error: Encountered an XML problem. Note that some XML errors
			may be severe enough to require error reporting at the HTTP layer,
			instead. Implementations MAY choose to report any or all XML
			errors at the HTTP layer.
	permission_failure: Client does not have permission to update this		permission_failure: Client does not have permission to update this
	URI.		URI.
	bad_cms_signature: Bad CMS signature.		bad_cms_signature: Bad CMS signature.
	object_already_present: An object is already present at this URI,		object_already_present: An object is already present at this URI,
	yet a hash attribute was not specified. A hash attribute must be		yet a "hash" attribute was not specified. A "hash" attribute must
	specified when overwriting or deleting an object. Perhaps client		be specified when overwriting or deleting an object. Perhaps
	and server are out of sync?		client and server are out of sync?
	no_object_present: There is no object present at this URI, yet a		no_object_present: There is no object present at this URI, yet a
	hash attribute was specified. Perhaps client and server are out		"hash" attribute was specified. Perhaps client and server are out
	of sync?		of sync?
	no_object_matching_hash The hash attribute supplied does not match		no_object_matching_hash The "hash" attribute supplied does not match
	the hash attribute of the object at this URI. Perhaps client and		the "hash" attribute of the object at this URI. Perhaps client
	server are out of sync?		and server are out of sync?
	consistency_problem: Server detected an update that looks like it		consistency_problem: Server detected an update that looks like it
	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.7. 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 3407 2015-09-25 21:05:28Z sra $		# $Id: rpki-publication.rnc 3595 2016-03-21 21:31:37Z sra $
	# 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 3 of the protocol.		# This is version 4 of the protocol.
	version = "3"		version = "4"
	# Top level PDU is either a query or a reply.		# Top level PDU is either a query or a reply.
	start |= element msg {		start |= element msg {
	attribute version { version },		attribute version { version },
	attribute type { "query" },		attribute type { "query" },
	query_elt*		query_elt*
	}		}
	start |= element msg {		start |= element msg {
	attribute version { version },		attribute version { version },
	attribute type { "reply" },		attribute type { "reply" },
	reply_elt*		reply_elt*
	}		}
	# PDUs allowed in queries and replies.
	query_elt = publish_query | withdraw_query | list_query
	reply_elt = publish_reply | withdraw_reply | list_reply | error_reply
	# Tag attributes for bulk operations.		# Tag attributes for bulk operations.
	tag = attribute tag { xsd:token { maxLength="1024" } }		tag = attribute tag { xsd:token { maxLength="1024" } }
	# Base64 encoded DER stuff.		# Base64 encoded DER stuff.
	base64 = xsd:base64Binary		base64 = xsd:base64Binary
	# Publication URIs.		# Publication URIs.
	uri = attribute uri { xsd:anyURI { maxLength="4096" } }		uri = attribute uri { xsd:anyURI { maxLength="4096" } }
	# Digest of an existing object (hexadecimal).		# Digest of an existing object (hexadecimal).
	hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }		hash = attribute hash { xsd:string { pattern = "[0-9a-fA-F]+" } }
	# Error codes.		# Error codes.
			error |= "xml_error"
	error |= "permission_failure"		error |= "permission_failure"
	error |= "bad_cms_signature"		error |= "bad_cms_signature"
	error |= "object_already_present"		error |= "object_already_present"
	error |= "no_object_present"		error |= "no_object_present"
	error |= "no_object_matching_hash"		error |= "no_object_matching_hash"
	error |= "consistency_problem"		error |= "consistency_problem"
	error |= "other_error"		error |= "other_error"
	# <publish/> element		# <publish/> query
	publish_query = element publish { tag?, uri, hash?, base64 }		query_elt |= element publish { tag, uri, hash?, base64 }
	publish_reply = element publish { tag?, uri }		# <withdraw/> query
	# <withdraw/> element		query_elt |= element withdraw { tag, uri, hash }
	withdraw_query = element withdraw { tag?, uri, hash }		# <success/> reply
	withdraw_reply = element withdraw { tag?, uri }
	# <list/> element		reply_elt |= element success { empty }
	list_query = element list { tag? }		# <list/> query and reply
	list_reply = element list { tag?, uri, hash }
	# <report_error/> element		query_elt |= element list { empty }
			reply_elt |= element list { uri, hash }
	error_reply = element report_error {		# <report_error/> reply
			reply_elt |= element report_error {
	tag?,		tag?,
	attribute error_code { error },		attribute error_code { error },
	element error_text { xsd:string { maxLength="512000" }}?,		element error_text { xsd:string { maxLength="512000" }}?,
	element failed_pdu { query_elt }?		element failed_pdu { query_elt }?
	}		}
	3. Examples		3. Examples
	Following are examples of various queries and the corresponding		Following are examples of various queries and the corresponding
	replies for the RPKI publication protocol.		replies for the RPKI publication protocol.
	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="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer">		tag="foo"
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
			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="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	hash="60d730635fce156f"		hash="01a97a70ac477f06"
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer">		tag="foo"
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
			SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
	</publish>		</publish>
	</msg>		</msg>
	3.3. <publish/> Reply		3.3. <withdraw/> Query
	<msg
	type="reply"
	version="3"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
	</msg>
	3.4. <withdraw/> Query
	<msg		<msg
	type="query"		type="query"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<withdraw		<withdraw
	hash="60d730635fce156f"		hash="01a97a70ac477f06"
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>		tag="foo"
			uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer"/>
	</msg>		</msg>
	3.5. <withdraw/> Reply		3.4. <success/> Reply
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<withdraw		<success/>
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer"/>
	</msg>		</msg>
	3.6. <report_error/> With Optional Elements		3.5. <report_error/> With Optional Elements
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<report_error		<report_error
	error_code="no_object_matching_hash">		error_code="no_object_matching_hash"
			tag="foo">
	<error_text>		<error_text>
	Can't delete an object I don't have		Can't delete an object I don't have
	</error_text>		</error_text>
	<failed_pdu>		<failed_pdu>
	<publish		<publish
	hash="60d730635fce156f"		hash="01a97a70ac477f06"
	uri="rsync://wombat.example/Alice/60d730635fce156f.cer">		tag="foo"
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50Li4u		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
			SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
	</publish>		</publish>
	</failed_pdu>		</failed_pdu>
	</report_error>		</report_error>
	</msg>		</msg>
	3.7. <report_error/> Without Optional Elements		3.6. <report_error/> Without Optional Elements
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<report_error		<report_error
	error_code="object_already_present"/>		error_code="object_already_present"
			tag="foo"/>
	</msg>		</msg>
	3.8. Error Handling With Multi-Element Queries		3.7. Error Handling With Multi-Element Queries
	3.8.1. Multi-Element Query		3.7.1. Multi-Element Query
	<msg		<msg
	type="query"		type="query"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<publish
	tag="Alice"		tag="Alice"
	uri="rsync://wombat.example/Alice/3bc51062973c458d.cer">		uri="rsync://wombat.example/Alice/01a97a70ac477f06.cer">
	QWxpY2U=		SGVsbG8sIG15IG5hbWUgaXMgQWxpY2U=
	</publish>		</publish>
	<withdraw		<withdraw
	hash="cd9fb1e148ccd844"		hash="f46a4198efa3070e"
	tag="Bob"		tag="Bob"
	uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>		uri="rsync://wombat.example/Bob/f46a4198efa3070e.cer"/>
	<publish		<publish
	tag="Carol"		tag="Carol"
	uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer">		uri="rsync://wombat.example/Carol/32e0544eeb510ec0.cer">
	Q2Fyb2w=		SGVsbG8sIG15IG5hbWUgaXMgQ2Fyb2w=
	</publish>		</publish>
	<list/>
	<withdraw		<withdraw
	hash="809a721743350c0c"		hash="421ee4ac65732d72"
	tag="Dave"		tag="Dave"
	uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>		uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
	<publish		<publish
	tag="Eve"		tag="Eve"
	uri="rsync://wombat.example/Eve/b9bae658d9657985.cer">		uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
	RXZl		SGVsbG8sIG15IG5hbWUgaXMgRXZl
	</publish>		</publish>
	</msg>		</msg>
	3.8.2. Successful Multi-Element Response		3.7.2. Successful Multi-Element Response
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish		<success/>
	tag="Alice"
	uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
	<withdraw
	tag="Bob"
	uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
	<publish
	tag="Carol"
	uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
	<list
	hash="f842c3e1858df8c8"
	uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
	<list
	hash="b139ca23414476bb"
	uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
	<list
	hash="1995e9544ba80191"
	uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
	<list
	hash="9c00b310c10a022c"
	uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
	<withdraw
	tag="Dave"
	uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>
	<publish
	tag="Eve"
	uri="rsync://wombat.example/Eve/b9bae658d9657985.cer"/>
	</msg>		</msg>
	3.8.3. Failure Multi-Element Response		3.7.3. Failure Multi-Element Response, First Error Only
	<msg		<msg
	type="reply"		type="reply"
	version="3"		version="4"
	xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">		xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
	<publish
	tag="Alice"
	uri="rsync://wombat.example/Alice/3bc51062973c458d.cer"/>
	<withdraw
	tag="Bob"
	uri="rsync://wombat.example/Bob/cd9fb1e148ccd844.cer"/>
	<publish
	tag="Carol"
	uri="rsync://wombat.example/Carol/b2dd7d8a70567a0e.cer"/>
	<list
	hash="f842c3e1858df8c8"
	uri="rsync://wombat.example/Fee/f842c3e1858df8c8.cer"/>
	<list
	hash="b139ca23414476bb"
	uri="rsync://wombat.example/Fie/b139ca23414476bb.cer"/>
	<list
	hash="1995e9544ba80191"
	uri="rsync://wombat.example/Foe/1995e9544ba80191.cer"/>
	<list
	hash="9c00b310c10a022c"
	uri="rsync://wombat.example/Fum/9c00b310c10a022c.cer"/>
	<report_error		<report_error
	error_code="no_object_matching_hash"		error_code="no_object_matching_hash"
	tag="Dave">		tag="Dave">
	<failed_pdu>		<failed_pdu>
	<withdraw		<withdraw
	hash="809a721743350c0c"		hash="421ee4ac65732d72"
	tag="Dave"		tag="Dave"
	uri="rsync://wombat.example/Dave/809a721743350c0c.cer"/>		uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
	</failed_pdu>		</failed_pdu>
	</report_error>		</report_error>
	</msg>		</msg>
			3.7.4. Failure Multi-Element Response, All Errors
			<msg
			type="reply"
			version="4"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<report_error
			error_code="no_object_matching_hash"
			tag="Dave">
			<failed_pdu>
			<withdraw
			hash="421ee4ac65732d72"
			tag="Dave"
			uri="rsync://wombat.example/Dave/421ee4ac65732d72.cer"/>
			</failed_pdu>
			</report_error>
			<report_error
			error_code="object_already_present"
			tag="Eve">
			<failed_pdu>
			<publish
			tag="Eve"
			uri="rsync://wombat.example/Eve/9dd859b01e5c2ebd.cer">
			SGVsbG8sIG15IG5hbWUgaXMgRXZl
			</publish>
			</failed_pdu>
			</report_error>
			</msg>
			3.8. <list/> Query
			<msg
			type="query"
			version="4"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<list/>
			</msg>
			3.9. <list/> Reply
			<msg
			type="reply"
			version="4"
			xmlns="http://www.hactrn.net/uris/rpki/publication-spec/">
			<list
			hash="eb719b72f0648cf4"
			uri="rsync://wombat.example/Fee/eb719b72f0648cf4.cer"/>
			<list
			hash="c7c50a68b7aa50bf"
			uri="rsync://wombat.example/Fie/c7c50a68b7aa50bf.cer"/>
			<list
			hash="f222481ded47445d"
			uri="rsync://wombat.example/Foe/f222481ded47445d.cer"/>
			<list
			hash="15b94e08713275bc"
			uri="rsync://wombat.example/Fum/15b94e08713275bc.cer"/>
			</msg>
	4. Operational Considerations		4. Operational Considerations
	There are two basic options open to the repository operator as to how		There are two basic options open to the repository operator as to how
	the publication tree is laid out. The first option is simple: each		the publication tree is laid out. The first option is simple: each
	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/
	skipping to change at page 15, line 29		skipping to change at page 15, line 22
	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 to the
	base_uri attribute values when setting up clients. In the example		"base_uri" attribute values when setting up clients. In the example
	above, assuming that Alice issues to Bob who in turn issues to Carol,		above, assuming that Alice issues to Bob who in turn issues to Carol,
	Alice has ceded control of a portion of her publication space to Bob,		Alice has ceded control of a portion of her publication space to Bob,
	who has in turn ceded a portion of that to Carol, and the base_uri		who has in turn ceded a portion of that to Carol, and the "base_uri"
	attributes in the <client/> setup messages should reflect this.		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 17, line 12		skipping to change at page 17, line 12
	Accordingly, as in most PKIs, good key management practices are		Accordingly, as in most PKIs, good key management practices are
	important.		important.
	7. References		7. References
	7.1. Normative References		7.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)", RFC		[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)",
	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", RFC		Protocol for Provisioning Resource Certificates",
	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		7.2. Informative References
	[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.
	Authors' Addresses		Authors' Addresses
	Samuel Weiler		Samuel Weiler
	Parsons		Parsons
	Email: weiler@tislabs.com		Email: weiler@tislabs.com
	Anuja Sonalker		Anuja Sonalker
	Battelle Memorial Institute		TowerSec Automotive Cyber Security
	Email: sonalkera@battelle.org		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. 89 change blocks.
	223 lines changed or deleted		214 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/