draft-ietf-sidr-rpki-oob-setup-04.txt		draft-ietf-sidr-rpki-oob-setup-05.txt
	Network Working Group R. Austein		Network Working Group R. Austein
	Internet-Draft Dragon Research Labs		Internet-Draft Dragon Research Labs
	Intended status: Standards Track April 11, 2016		Intended status: Standards Track December 21, 2016
	Expires: October 13, 2016		Expires: June 24, 2017
	An Out-Of-Band Setup Protocol For RPKI Production Services		An Out-Of-Band Setup Protocol For RPKI Production Services
	draft-ietf-sidr-rpki-oob-setup-04		draft-ietf-sidr-rpki-oob-setup-05
	Abstract		Abstract
	This note describes a simple out-of-band protocol to ease setup of		This note describes a simple out-of-band protocol to ease setup of
	the RPKI provisioning and publication protocols between two parties.		the RPKI provisioning and publication protocols between two parties.
	The protocol is encoded in a small number of XML messages, which can		The protocol is encoded in a small number of XML messages, which can
	be passed back and forth by any mutually agreeable secure means.		be passed back and forth by any mutually agreeable secure means.
	This setup protocol is not part of the provisioning or publication		This setup protocol is not part of the provisioning or publication
	protocol, rather, it is intended to simplify configuration of these		protocol, rather, it is intended to simplify configuration of these
	skipping to change at page 1, line 38		skipping to change at page 1, line 38
	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 October 13, 2016.		This Internet-Draft will expire on June 24, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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
	2. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3		2. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3
	4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5		4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Common Protocol Elements . . . . . . . . . . . . . . . . 5		5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6		5.1. Common Protocol Elements . . . . . . . . . . . . . . . . 6
	4.2.1. <child_request/> . . . . . . . . . . . . . . . . . . 6		5.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
	4.2.2. <parent_response/> . . . . . . . . . . . . . . . . . 7		5.2.1. <child_request/> . . . . . . . . . . . . . . . . . . 6
	4.2.3. <publisher_request/> . . . . . . . . . . . . . . . . 9		5.2.2. <parent_response/> . . . . . . . . . . . . . . . . . 7
	4.2.4. <repository_response/> . . . . . . . . . . . . . . . 10		5.2.3. <publisher_request/> . . . . . . . . . . . . . . . . 9
	4.3. <authorization/> . . . . . . . . . . . . . . . . . . . . 11		5.2.4. <repository_response/> . . . . . . . . . . . . . . . 10
	4.4. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 12		5.3. <authorization/> . . . . . . . . . . . . . . . . . . . . 11
	5. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 13		5.4. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 12
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	9. Normative References . . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
			10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
			10.1. Normative References . . . . . . . . . . . . . . . . . . 19
			10.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 19		Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
	1. Introduction		1. Introduction
	This note describes a small XML-based out-of-band protocol used to		This note describes a small XML-based out-of-band protocol used to
	set up relationships between parents and children in the RPKI		set up relationships between parents and children in the RPKI
	provisioning protocol ([RFC6492]) and between publishers and		provisioning protocol ([RFC6492]) and between publishers and
	repositories in the RPKI publication protocol		repositories in the RPKI publication protocol
	([I-D.ietf-sidr-publication]).		([I-D.ietf-sidr-publication]).
	The basic function of this protocol is public key exchange, in the		The basic function of this protocol is public key exchange, in the
	skipping to change at page 3, line 7		skipping to change at page 3, line 10
	The underlying transport for this protocol is deliberately		The underlying transport for this protocol is deliberately
	unspecified. It might be a USB stick, a web interface secured with		unspecified. It might be a USB stick, a web interface secured with
	conventional HTTPS, PGP-signed email, a T-shirt printed with a QR		conventional HTTPS, PGP-signed email, a T-shirt printed with a QR
	code, or a carrier pigeon.		code, or a carrier pigeon.
	Since much of the purpose of this protocol is key exchange,		Since much of the purpose of this protocol is key exchange,
	authentication and integrity of the key exchange MUST be ensured via		authentication and integrity of the key exchange MUST be ensured via
	external means. Typically such means will tie directly to a new or		external means. Typically such means will tie directly to a new or
	existing business relationship		existing business relationship
	2. Overview of the BPKI		2. History
			The protocol described in this document grew out of a series of
			workshops held starting in 2010, at which it became clear that manual
			configuration of keying material and service URLs was both error
			prone and unnecessarily confusing. The basic mechanism and semantics
			have been essentially unchanged since the earliest versions of the
			protocol, but there were several workshop-driven syntax changes and
			simplifications before the protocol made its way into the IETF, and a
			few more simplifications and minor extensions have occurred since
			that time.
			3. Overview of the BPKI
	Several protocols related to RPKI provisioning use signed CMS		Several protocols related to RPKI provisioning use signed CMS
	messages ([RFC5652]) to authenticate the underlying XML-based		messages ([RFC5652]) to authenticate the underlying XML-based
	protocols. Verification of these CMS messages requires X.509		protocols. Verification of these CMS messages requires X.509
	certificates. The PKI that holds these certificates is distinct from		certificates. The PKI that holds these certificates is distinct from
	the RPKI, and contains no RFC 3779 resources. We refer to this as		the RPKI, and contains no RFC 3779 resources. We refer to this as
	the "Business PKI" (BPKI), to distinguish it from the RPKI. The "B"		the "Business PKI" (BPKI), to distinguish it from the RPKI. The "B"
	is a hint that the certificate relationships in the BPKI are likely		is a hint that the certificate relationships in the BPKI are likely
	to follow and become part of existing contractual relationships		to follow and become part of existing contractual relationships
	between the issuers and subjects of this PKI.		between the issuers and subjects of this PKI.
	skipping to change at page 5, line 5		skipping to change at page 5, line 19
	by this protocol at the time this document was written are what a		by this protocol at the time this document was written are what a
	reader familiar with the technology would probably expect: RSA keys		reader familiar with the technology would probably expect: RSA keys
	with lengths in the 2048-4096 bit range, SHA-2 digests, and a few		with lengths in the 2048-4096 bit range, SHA-2 digests, and a few
	common X.509v3 extensions (principally Basic Constraints, Authority		common X.509v3 extensions (principally Basic Constraints, Authority
	Key Identifier, and Subject Key Identifier). Since the most likely		Key Identifier, and Subject Key Identifier). Since the most likely
	usage is a cross-certification operation in which the recipient		usage is a cross-certification operation in which the recipient
	simply extracts the Subject Name and public key after checking the		simply extracts the Subject Name and public key after checking the
	self-signature and discards the rest of the incoming certificate, the		self-signature and discards the rest of the incoming certificate, the
	practical value of esoteric X.509v3 extensions is somewhat limited.		practical value of esoteric X.509v3 extensions is somewhat limited.
	3. Terminology		4. 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].
	All of the protocols configured by this setup protocol have their own		All of the protocols configured by this setup protocol have their own
	terminology for their actors, but in the context of this protocol		terminology for their actors, but in the context of this protocol
	that terminology becomes somewhat confusing. All of the players in		that terminology becomes somewhat confusing. All of the players in
	this setup protocol issue certificates, are the subjects of other		this setup protocol issue certificates, are the subjects of other
	certificates, operate servers, and, in most cases, act as clients for		certificates, operate servers, and, in most cases, act as clients for
	skipping to change at page 5, line 36		skipping to change at page 6, line 5
	protocol defined in [I-D.ietf-sidr-publication].		protocol defined in [I-D.ietf-sidr-publication].
	Repository: An entity acting in the server role of the publication		Repository: An entity acting in the server role of the publication
	protocol defined in [I-D.ietf-sidr-publication].		protocol defined in [I-D.ietf-sidr-publication].
	Note that a given entity might act in more than one of these roles;		Note that a given entity might act in more than one of these roles;
	for example, in one of the simplest cases, the child is the same		for example, in one of the simplest cases, the child is the same
	entity as the publisher, while the parent is the same entity as the		entity as the publisher, while the parent is the same entity as the
	repository.		repository.
	4. Protocol Elements		5. Protocol Elements
	Each message in the protocol is a distinct XML element in the		Each message in the protocol is a distinct XML element in the
	"http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.		"http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.
	4.1. Common Protocol Elements		The outermost XML element of each message contains a version
			attribute. This document describes version 1 of the protocol.
	The first XML attribute in each message is a version field. This		5.1. Common Protocol Elements
	document describes version 1 of the protocol.
	Most messages contain, among other things, a self-signed BPKI X.509		Most messages contain, among other things, a self-signed BPKI X.509
	certificate. These certificates are represented as XML elements		certificate. These certificates are represented as XML elements
	whose text value is the Base64 text encoding the DER representation		whose text value is the Base64 text encoding the DER representation
	of the X.509 certificate.		of the X.509 certificate.
	A number of attributes contain "handles". A handle in this protocol		A number of attributes contain "handles". A handle in this protocol
	is a text string in the US-ASCII character set consisting of letters,		is a text string in the US-ASCII character set consisting of letters,
	digits, and the special characters "/", "-", and "_". This protocol		digits, and the special characters "/", "-", and "_". This protocol
	places no special semantics on the structure of these handles,		places no special semantics on the structure of these handles,
	although implementations might. Handles are protocol elements, not		although implementations might. Handles are protocol elements, not
	necessarily meaningful to humans, thus the simplicity of a restricted		necessarily meaningful to humans, thus the simplicity of a restricted
	character set makes more sense than the complex rules which would be		character set makes more sense than the complex rules which would be
	needed for internationalized text.		needed for internationalized text.
	Most messages allow an optional "tag" attribute. This is an opaque		Most messages allow an optional "tag" attribute. This is an opaque
	cookie supplied by the client in a particular exchange and echoed by		cookie supplied by the client in a particular exchange and echoed by
	the server; the intent is to simplify the process of matching a		the server; the intent is to simplify the process of matching a
	response received by the client with an outstanding request.		response received by the client with an outstanding request.
	4.2. Protocol Messages		5.2. Protocol Messages
	The core of this protocol consists of four message types,		The core of this protocol consists of four message types,
	representing the basic request and response semantics needed to		representing the basic request and response semantics needed to
	configure a RPKI engine to talk to its parent and its repository via		configure a RPKI engine to talk to its parent and its repository via
	the provisioning and publication protocols, respectively.		the provisioning and publication protocols, respectively.
	4.2.1. <child_request/>		5.2.1. <child_request/>
	The <child_request/> message is an initial setup request from a		The <child_request/> message is an initial setup request from a
	provisioning protocol child to its provisioning protocol parent.		provisioning protocol child to its provisioning protocol parent.
	Fields in the <child_request/> message:		Fields in the <child_request/> message:
	version: The version attribute specifies the protocol version. This		version: The version attribute specifies the protocol version. This
	note describes protocol version 1.		note describes protocol version 1.
	tag: The child MAY include a "tag" attribute in the request message.		tag: The child MAY include a "tag" attribute in the request message.
	skipping to change at page 7, line 7		skipping to change at page 7, line 18
	child_bpki_ta: The <child_bpki_ta/> element is the child's BPKI		child_bpki_ta: The <child_bpki_ta/> element is the child's BPKI
	identity, a self-signed X.509 BPKI certificate, encoded in Base64.		identity, a self-signed X.509 BPKI certificate, encoded in Base64.
	This CA certificate will be the issuer of the BPKI EE certificates		This CA certificate will be the issuer of the BPKI EE certificates
	corresponding to private keys that the child will use when sending		corresponding to private keys that the child will use when sending
	provisioning protocol messages to the parent.		provisioning protocol messages to the parent.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<child_request		<child_request
	child_handle="Bob"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		child_handle="Bob">
	<child_bpki_ta>		<child_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</child_bpki_ta>		</child_bpki_ta>
	</child_request>		</child_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4.2.2. <parent_response/>		5.2.2. <parent_response/>
	The <parent_response/> message is a response from a provisioning		The <parent_response/> message is a response from a provisioning
	protocol parent to a provisioning protocol child that had previously		protocol parent to a provisioning protocol child that had previously
	sent a <child_request/> message.		sent a <child_request/> message.
	Fields in the <parent_response/> message:		Fields in the <parent_response/> message:
	version: The version attribute specifies the protocol version. This		version: The version attribute specifies the protocol version. This
	note describes protocol version 1.		note describes protocol version 1.
	skipping to change at page 8, line 13		skipping to change at page 8, line 21
	identity, a self-signed X.509 BPKI certificate.		identity, a self-signed X.509 BPKI certificate.
	This certificate is the issuer of the BPKI EE certificates		This certificate is the issuer of the BPKI EE certificates
	corresponding to private keys that the parent will use to sign		corresponding to private keys that the parent will use to sign
	provisioning protocol messages to the child.		provisioning protocol messages to the child.
	offer: If an <offer/> element is present, the parent is offering		offer: If an <offer/> element is present, the parent is offering
	publication service to the child. The <offer/> element, if		publication service to the child. The <offer/> element, if
	present, is empty.		present, is empty.
	referral: If a <referral/> element is present, it suggests a third-		referral: If <referral/> elements are present, they suggests third-
	party publication services that the child might use, and contains:		party publication services which the child might use, and contain:
	referrer: A referrer attribute, containing the handle by which		referrer: A referrer attribute, containing the handle by which
	the publication repository knows the parent,		the publication repository knows the parent,
	contact_uri: An optional contact_uri attribute that the child may		contact_uri: An optional contact_uri attribute that the child may
	be able to follow for more information, and		be able to follow for more information, and
	Authorization token: The text of the <referral/> element is the		Authorization token: The text of the <referral/> element is the
	Base64 encoding of a signed authorization token granting the		Base64 encoding of a signed authorization token granting the
	child the right to use a portion of the parent's namespace at		child the right to use a portion of the parent's namespace at
	the publication repository in question. See Section 4.3 for		the publication repository in question. See Section 5.3 for
	details on the authorization token.		details on the authorization token.
			A parent is unlikely to need to send both <offer> and <referral>
			elements, but strictly speaking they are not mutually exclusive, so a
			parent which really needs to express that it both offers repository
			service to its child and is also willing to refer its child to one or
			more other repository servers can do so.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Bob-42"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	parent_handle="Alice"
	service_uri="http://a.example/up-down/Alice/Bob-42"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		service_uri="http://a.example/up-down/Alice/Bob-42"
			child_handle="Bob-42"
			parent_handle="Alice">
	<parent_bpki_ta>		<parent_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</parent_bpki_ta>		</parent_bpki_ta>
	<offer/>		<offer/>
	</parent_response>		</parent_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Carol"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	parent_handle="Bob"
	service_uri="http://bob.example/up-down/Bob/Carol"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		service_uri="http://bob.example/up-down/Bob/Carol"
			child_handle="Carol"
			parent_handle="Bob">
	<parent_bpki_ta>		<parent_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</parent_bpki_ta>		</parent_bpki_ta>
	<referral		<referral
	referrer="Alice/Bob-42">		referrer="Alice/Bob-42">
	R28sIGxlbW1pbmdzLCBnbyE=		R28sIGxlbW1pbmdzLCBnbyE=
	</referral>		</referral>
	</parent_response>		</parent_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4.2.3. <publisher_request/>		5.2.3. <publisher_request/>
	The <publisher_request/> message is a setup request from a publisher		The <publisher_request/> message is a setup request from a publisher
	to a repository.		to a repository.
	Fields in the <publisher_request/> message:		Fields in the <publisher_request/> message:
	version: The version attribute specifies the protocol version. This		version: The version attribute specifies the protocol version. This
	note describes protocol version 1.		note describes protocol version 1.
	tag: The publisher MAY include a "tag" attribute in the request		tag: The publisher MAY include a "tag" attribute in the request
	skipping to change at page 10, line 4		skipping to change at page 10, line 19
	publication protocol messages to the repository.		publication protocol messages to the repository.
	referral: If a <referral/> element is present, it contains:		referral: If a <referral/> element is present, it contains:
	referrer: A referrer attribute containing the publication handle		referrer: A referrer attribute containing the publication handle
	of the referring parent, and		of the referring parent, and
	Authorization token: The text of the <referral/> element is the		Authorization token: The text of the <referral/> element is the
	Base64 encoding of a signed authorization token granting the		Base64 encoding of a signed authorization token granting the
	publisher the right to use a portion of its parent's namespace		publisher the right to use a portion of its parent's namespace
	at this repository. See Section 4.3 for details on the		at this repository. See Section 5.3 for details on the
	authorization token.		authorization token.
	These fields are copies of values that a parent provided to the		These fields are copies of values that a parent provided to the
	child in the <parent_response/> message (see Section 4.2.2). The		child in the <parent_response/> message (see Section 5.2.2). The
	referrer attribute is present to aid lookup of the corresponding		referrer attribute is present to aid lookup of the corresponding
	certificate by the repository. Note that the repository operator		certificate by the repository. Note that the repository operator
	makes the final decision on whether to grant publication service		makes the final decision on whether to grant publication service
	to the prospective publisher. The <referral/> element just		to the prospective publisher. The <referral/> element just
	conveys a parent's grant of permission to use a portion of that		conveys a parent's grant of permission to use a portion of that
	parent's namespace.		parent's namespace.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<publisher_request		<publisher_request
	publisher_handle="Bob"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		tag="A0001"
			publisher_handle="Bob">
	<publisher_bpki_ta>		<publisher_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</publisher_bpki_ta>		</publisher_bpki_ta>
	</publisher_request>		</publisher_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4.2.4. <repository_response/>		5.2.4. <repository_response/>
	The <repository_response/> message is a repository's response to a		The <repository_response/> message is a repository's response to a
	publisher which has previously sent a <publisher_request/> message.		publisher which has previously sent a <publisher_request/> message.
	Fields in the <repository_response/> message:		Fields in the <repository_response/> message:
	version: The version attribute specifies the protocol version. This		version: The version attribute specifies the protocol version. This
	note describes protocol version 1.		note describes protocol version 1.
	tag: If the <publisher_request/> message included a "tag" attribute,		tag: If the <publisher_request/> message included a "tag" attribute,
	skipping to change at page 11, line 17		skipping to change at page 11, line 32
	rrdp_notification_uri: The optional rrdp_notification_uri attribute		rrdp_notification_uri: The optional rrdp_notification_uri attribute
	is the URI for the RRDP notification file covering the publication		is the URI for the RRDP notification file covering the publication
	space allocated to the publisher ([I-D.ietf-sidr-delta-protocol]).		space allocated to the publisher ([I-D.ietf-sidr-delta-protocol]).
	repository_bpki_ta: The <repository_bpki_ta/> element is the		repository_bpki_ta: The <repository_bpki_ta/> element is the
	repository's BPKI identity, a self-signed X.509 BPKI certificate.		repository's BPKI identity, a self-signed X.509 BPKI certificate.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<repository_response		<repository_response
	publisher_handle="Alice/Bob-42"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"		version="1"
			tag="A0001"
	service_uri="http://a.example/publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
			publisher_handle="Alice/Bob-42"
	sia_base="rsync://a.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/Alice/Bob-42/"
	tag="A0001"		rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
	version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<repository_bpki_ta>		<repository_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</repository_bpki_ta>		</repository_bpki_ta>
	</repository_response>		</repository_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4.3. <authorization/>		5.3. <authorization/>
	The <authorization/> element is a separate message which is signed		The <authorization/> element is a separate message which is signed
	with CMS, then included as the Base64 content of <referral/> elements		with CMS, then included as the Base64 content of <referral/> elements
	in other messages.		in other messages.
	The eContentType for the signed CMS message is id-ct-xml.		The eContentType for the signed CMS message is id-ct-xml.
	Fields in the <authorization/> element:		Fields in the <authorization/> element:
	version: The version attribute specifies the protocol version. This		version: The version attribute specifies the protocol version. This
	note describes protocol version 1.		note describes protocol version 1.
	authorized_sia_base: The value of the authorized_sia_base attribute		authorized_sia_base: The value of the authorized_sia_base attribute
	is the rsync:// URI of the base of the namespace which the		is the rsync:// URI of the base of the namespace which the
	referrer is delegating.		referrer is delegating.
	bpki_ta: The <bpki_ta/> element is the identity of the entity to		BPKI TA: The text of the <authorization/> element is the identity of
	whom the referrer is delegating the portion of the namespace named		the entity to whom the referrer is delegating the portion of the
	in the authorized_sia_base attribute. The identity is represented		namespace named in the authorized_sia_base attribute, represented
	as a self-signed X.509 BPKI certificate.		as a Base64-encoded self-signed X.509 BPKI certificate.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<authorization		<authorization
	authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</authorization>		</authorization>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4.4. <error/>		5.4. <error/>
	The <error/> element is an optional message which can be used in		The <error/> element is an optional message which can be used in
	response to any of the core protocol messages described in		response to any of the core protocol messages described in
	Section 4.2.		Section 5.2.
	Whether an <error/> element is an appropriate way to signal errors		Whether an <error/> element is an appropriate way to signal errors
	back to the sender of a protocol message depends on details of the		back to the sender of a protocol message depends on details of the
	implementation which are outside this specification. For example, if		implementation which are outside this specification. For example, if
	this protocol is embedded in a web portal interface which is designed		this protocol is embedded in a web portal interface which is designed
	to let a human being upload and download these messages via upload		to let a human being upload and download these messages via upload
	and download forms, a human-readable error message may be more		and download forms, a human-readable error message may be more
	appropriate. On the other hand, a portal intended to be driven by a		appropriate. On the other hand, a portal intended to be driven by a
	robotic client might well want to use an <error/> message to signal		robotic client might well want to use an <error/> message to signal
	errors. Similar arguments apply to non-web encapsulations (email,		errors. Similar arguments apply to non-web encapsulations (email,
	skipping to change at page 13, line 7		skipping to change at page 13, line 21
	authentication-failure: Receiver could not authenticate the		authentication-failure: Receiver could not authenticate the
	offending message.		offending message.
	refused: Receiver refused to perform the requested action.		refused: Receiver refused to perform the requested action.
	Offending message: The <error/> element contains a verbatim copy of		Offending message: The <error/> element contains a verbatim copy of
	the message to which this error applies.		the message to which this error applies.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<error		<error
	reason="refused"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		reason="refused">
	<child_request		<child_request
			xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
			version="1"
	child_handle="Carol">		child_handle="Carol">
	<child_bpki_ta>		<child_bpki_ta>
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</child_bpki_ta>		</child_bpki_ta>
	</child_request>		</child_request>
	</error>		</error>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	5. Protocol Walk-Through		6. Protocol Walk-Through
	This section walks through a few simple examples of the protocol in		This section walks through a few simple examples of the protocol in
	use, and stars our old friends, Alice, Bob, and Carol. In this		use, and stars our old friends, Alice, Bob, and Carol. In this
	example, Alice is the root of a RPKI tree, Bob wants to get address		example, Alice is the root of a RPKI tree, Bob wants to get address
	and ASN resources from Alice, and Carol wants to get some of those		and ASN resources from Alice, and Carol wants to get some of those
	resources in turn from Bob. Alice offers publication service, which		resources in turn from Bob. Alice offers publication service, which
	is used by all three.		is used by all three.
	Alice, Bob, and Carol each generates his or her own self-signed BPKI		Alice, Bob, and Carol each generates his or her own self-signed BPKI
	certificate.		certificate.
	Bob constructs a <child_request/> message and sends it to Alice:		Bob constructs a <child_request/> message and sends it to Alice:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<child_request		<child_request
	child_handle="Bob"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		child_handle="Bob">
	<child_bpki_ta>		<child_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</child_bpki_ta>		</child_bpki_ta>
	</child_request>		</child_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	o Bob's preferred handle is "Bob", so Bob uses that when setting		o Bob's preferred handle is "Bob", so Bob uses that when setting
	child_handle.		child_handle.
	o <child_bpki_ta/> is Bob's self-signed BPKI certificate.		o <child_bpki_ta/> is Bob's self-signed BPKI certificate.
	skipping to change at page 14, line 14		skipping to change at page 14, line 35
	provisioning protocol CMS message just by looking at the URL, so the		provisioning protocol CMS message just by looking at the URL, so the
	service URL she provides to Bob includes both her name and Bob's.		service URL she provides to Bob includes both her name and Bob's.
	Alice offers publication service, so she offers to let Bob use it;		Alice offers publication service, so she offers to let Bob use it;
	Alice doesn't have to do this, she could just omit this and leave Bob		Alice doesn't have to do this, she could just omit this and leave Bob
	to find publication service on his own, but Alice is trying to be		to find publication service on his own, but Alice is trying to be
	helpful to her customer Bob. Bob doesn't have to accept Alice's		helpful to her customer Bob. Bob doesn't have to accept Alice's
	offer, but may choose to do so.		offer, but may choose to do so.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Bob-42"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	parent_handle="Alice"
	service_uri="http://a.example/up-down/Alice/Bob-42"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		service_uri="http://a.example/up-down/Alice/Bob-42"
			child_handle="Bob-42"
			parent_handle="Alice">
	<parent_bpki_ta>		<parent_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</parent_bpki_ta>		</parent_bpki_ta>
	<offer/>		<offer/>
	</parent_response>		</parent_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	o <parent_bpki_ta/> is Alice's own self-signed BPKI certificate.		o <parent_bpki_ta/> is Alice's own self-signed BPKI certificate.
	Bob receives Alice's <parent_response/> and extracts the fields Bob's		Bob receives Alice's <parent_response/> and extracts the fields Bob's
	RPKI engine will need to know about (child_handle, parent_handle,		RPKI engine will need to know about (child_handle, parent_handle,
	service_uri, and <parent_bpki_ta/>). Bob also sees the repository		service_uri, and <parent_bpki_ta/>). Bob also sees the repository
	offer, decides to take Alice up on this offer, and constructs a		offer, decides to take Alice up on this offer, and constructs a
	<publisher_request/> message accordingly:		<publisher_request/> message accordingly:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<publisher_request		<publisher_request
	publisher_handle="Bob"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		tag="A0001"
			publisher_handle="Bob">
	<publisher_bpki_ta>		<publisher_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</publisher_bpki_ta>		</publisher_bpki_ta>
	</publisher_request>		</publisher_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Alice receives Bob's request to use Alice's publication service,		Alice receives Bob's request to use Alice's publication service,
	decides to honor the offer she made, and sends back a		decides to honor the offer she made, and sends back a
	<repository_response/> message in response. Alice recognizes Bob as		<repository_response/> message in response. Alice recognizes Bob as
	one of her own children, because she's already seen Bob's self-signed		one of her own children, because she's already seen Bob's self-signed
	BPKI certificate, so she allocates publication space to Bob under her		BPKI certificate, so she allocates publication space to Bob under her
	own publication space, so that relying parties who rsync her products		own publication space, so that relying parties who rsync her products
	will pick up Bob's products automatically without needing an		will pick up Bob's products automatically without needing an
	additional fetch operation.		additional fetch operation.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<repository_response		<repository_response
	publisher_handle="Alice/Bob-42"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"		version="1"
			tag="A0001"
	service_uri="http://a.example/publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
			publisher_handle="Alice/Bob-42"
	sia_base="rsync://a.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/Alice/Bob-42/"
	tag="A0001"		rrdp_notification_uri="https://rpki.example/rrdp/notify.xml">
	version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<repository_bpki_ta>		<repository_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</repository_bpki_ta>		</repository_bpki_ta>
	</repository_response>		</repository_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Bob should now have everything he needs to talk to Alice both for		Bob should now have everything he needs to talk to Alice both for
	provisioning and for publication.		provisioning and for publication.
	A more interesting case is Bob's child, Carol. Carol wants to get		A more interesting case is Bob's child, Carol. Carol wants to get
	skipping to change at page 15, line 37		skipping to change at page 16, line 10
	operate a publication service. Bob doesn't have a publication		operate a publication service. Bob doesn't have a publication
	service of his own to offer, but he can refer Carol to Alice, along		service of his own to offer, but he can refer Carol to Alice, along
	with his permission for Carol to use a portion of the namespace that		with his permission for Carol to use a portion of the namespace that
	Alice gave him.		Alice gave him.
	Carol's <child_request/> to Bob looks very similar to Bob's earlier		Carol's <child_request/> to Bob looks very similar to Bob's earlier
	request to Alice:		request to Alice:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<child_request		<child_request
	child_handle="Carol"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		child_handle="Carol">
	<child_bpki_ta>		<child_bpki_ta>
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</child_bpki_ta>		</child_bpki_ta>
	</child_request>		</child_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Bob's <parent_response/> to Carol also looks a lot like Alice's		Bob's <parent_response/> to Carol also looks a lot like Alice's
	response to Bob, except that Bob includes a <referral/> element		response to Bob, except that Bob includes a <referral/> element
	instead of an <offer/> element. Carol is an only child, so Bob		instead of an <offer/> element. Carol is an only child, so Bob
	leaves her name alone:		leaves her name alone:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Carol"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	parent_handle="Bob"
	service_uri="http://bob.example/up-down/Bob/Carol"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		service_uri="http://bob.example/up-down/Bob/Carol"
			child_handle="Carol"
			parent_handle="Bob">
	<parent_bpki_ta>		<parent_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</parent_bpki_ta>		</parent_bpki_ta>
	<referral		<referral
	referrer="Alice/Bob-42">		referrer="Alice/Bob-42">
	R28sIGxlbW1pbmdzLCBnbyE=		R28sIGxlbW1pbmdzLCBnbyE=
	</referral>		</referral>
	</parent_response>		</parent_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	skipping to change at page 16, line 34		skipping to change at page 17, line 7
	repository. The Base64-encoded authorization token is an		repository. The Base64-encoded authorization token is an
	<authorization/> element in a CMS message that can be verified		<authorization/> element in a CMS message that can be verified
	against Bob's self-signed BPKI certificate, using a BPKI EE		against Bob's self-signed BPKI certificate, using a BPKI EE
	certificate included in the CMS wrapper. The <authorization/> text		certificate included in the CMS wrapper. The <authorization/> text
	is Carol's self-signed BPKI certificate; Bob's signature over this		is Carol's self-signed BPKI certificate; Bob's signature over this
	element indicates Bob's permission for Carol to use the indicated		element indicates Bob's permission for Carol to use the indicated
	portion of Bob's publication space.		portion of Bob's publication space.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<authorization		<authorization
	authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</authorization>		</authorization>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Carol, not wanting to have to run a publication service, presents		Carol, not wanting to have to run a publication service, presents
	Bob's referral to Alice in the hope that Alice will let Carol use		Bob's referral to Alice in the hope that Alice will let Carol use
	Alice's publication service. So Carol constructs a		Alice's publication service. So Carol constructs a
	<publisher_request/> message including the referral information		<publisher_request/> message including the referral information
	received from Bob, and sends it all to Alice:		received from Bob, and sends it all to Alice:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<publisher_request		<publisher_request
	publisher_handle="Carol"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	tag="A0002"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		tag="A0002"
			publisher_handle="Carol">
	<publisher_bpki_ta>		<publisher_bpki_ta>
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</publisher_bpki_ta>		</publisher_bpki_ta>
	<referral		<referral
	referrer="Alice/Bob-42">		referrer="Alice/Bob-42">
	R28sIGxlbW1pbmdzLCBnbyE=		R28sIGxlbW1pbmdzLCBnbyE=
	</referral>		</referral>
	</publisher_request>		</publisher_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Alice sees the signed authorization token Bob gave to Carol, checks		Alice sees the signed authorization token Bob gave to Carol, checks
	its signature, and unpacks it. When the signature proves valid and		its signature, and unpacks it. When the signature proves valid and
	the contained BPKI TA matches Carol's, Alice knows that Bob is		the contained BPKI TA matches Carol's, Alice knows that Bob is
	willing to let Carol use a portion of Bob's namespace. Given this,		willing to let Carol use a portion of Bob's namespace. Given this,
	Alice is willing to provide publication service to Carol in the		Alice is willing to provide publication service to Carol in the
	subtree allocated by Bob for this purpose, so Alice sends back a		subtree allocated by Bob for this purpose, so Alice sends back a
	<repository_response/>:		<repository_response/>:
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<repository_response		<repository_response
	publisher_handle="Alice/Bob-42/Carol"		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/"
	service_uri="http://a.example/publication/Alice/Bob-42/Carol"
	sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"
	tag="A0002"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		tag="A0002"
			service_uri="http://a.example/publication/Alice/Bob-42/Carol"
			publisher_handle="Alice/Bob-42/Carol"
			sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/">
	<repository_bpki_ta>		<repository_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</repository_bpki_ta>		</repository_bpki_ta>
	</repository_response>		</repository_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	Once Carol receives this response, Carol should be good to go.		Once Carol receives this response, Carol should be good to go.
	In theory the publication referral mechanism can extend indefinitely		In theory the publication referral mechanism can extend indefinitely
	(for example, Carol can refer her child Dave to Alice for publication		(for example, Carol can refer her child Dave to Alice for publication
	service and it should all work). In practice, this has not yet been		service and it should all work). In practice, this has not yet been
	implemented, much less tested. In order to keep the protocol		implemented, much less tested. In order to keep the protocol
	relatively simple, we've deliberately ignored perverse cases such as		relatively simple, we've deliberately ignored perverse cases such as
	Bob being willing to refer Carol to Alice but not wanting Carol to be		Bob being willing to refer Carol to Alice but not wanting Carol to be
	allowed to refer Dave to Alice.		allowed to refer Dave to Alice.
	6. IANA Considerations		Any RPKI operator is free to run their own publication service should
			they feel a need to do so, and a child need not accept any particular
			<offer/> or <referral/>. In general, having a smaller number of
			larger publication repositories is probably good for overall system
			performance, because it will tend to reduce the number of distinct
			repositories from which each relying party will need to fetch, but
			the decision on where to publish is up to individual RPKI CA
			operators and out of scope for this protocol.
			7. IANA Considerations
	This document makes no request of IANA.		This document makes no request of IANA.
	7. Security Considerations		8. Security Considerations
	As stated in Section 1, the basic function of this protocol is an		As stated in Section 1, the basic function of this protocol is an
	exchange of public keys to be used as BPKI trust anchors. Integrity		exchange of public keys to be used as BPKI trust anchors. Integrity
	and authentication of these exchanges MUST be ensured via external		and authentication of these exchanges MUST be ensured via external
	mechanisms deliberately left unspecified in this protocol.		mechanisms deliberately left unspecified in this protocol.
	8. Acknowledgements		9. Acknowledgements
	The author would like to thank: Byron Ellacott, George Michaelson,		The author would like to thank: Byron Ellacott, George Michaelson,
	Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush,		Leif Johansson, Matsuzaki Yoshinobu, Michael Elkins, Randy Bush,
	Seiichi Kawamura, Tim Bruijnzeels, and anybody else who helped along		Seiichi Kawamura, Tim Bruijnzeels, and anybody else who helped along
	the way but whose name the author has temporarily forgotten.		the way but whose name the author has temporarily forgotten.
	9. Normative References		10. References
			10.1. Normative References
	[I-D.ietf-sidr-delta-protocol]		[I-D.ietf-sidr-delta-protocol]
	Bruijnzeels, T., Muravskiy, O., Weber, B., Austein, R.,		Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
	and D. Mandelberg, "RPKI Repository Delta Protocol",		"RPKI Repository Delta Protocol", draft-ietf-sidr-delta-
	draft-ietf-sidr-delta-protocol-02 (work in progress),		protocol-04 (work in progress), September 2016.
	March 2016.
	[I-D.ietf-sidr-publication]		[I-D.ietf-sidr-publication]
	Weiler, S., Sonalker, A., and R. Austein, "A Publication		Weiler, S., Sonalker, A., and R. Austein, "A Publication
	Protocol for the Resource Public Key Infrastructure		Protocol for the Resource Public Key Infrastructure
	(RPKI)", draft-ietf-sidr-publication-08 (work in		(RPKI)", draft-ietf-sidr-publication-09 (work in
	progress), March 2016.		progress), September 2016.
	[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.
			[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
			Protocol for Provisioning Resource Certificates",
			RFC 6492, February 2012.
			10.2. Informative 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, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[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
	Protocol for Provisioning Resource Certificates",
	RFC 6492, February 2012.
	Appendix A. RelaxNG Schema		Appendix A. RelaxNG Schema
	Here is a RelaxNG schema describing the protocol elements.		Here is a RelaxNG schema describing the protocol elements.
	# $Id: rpki-setup.rnc 3618 2016-04-11 21:19:50Z sra $		# $Id: rpki-setup.rnc 3618 2016-04-11 21:19:50Z sra $
	default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"		default namespace = "http://www.hactrn.net/uris/rpki/rpki-setup/"
	version = "1"		version = "1"
	base64 = xsd:base64Binary { maxLength="512000" }		base64 = xsd:base64Binary { maxLength="512000" }
	handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" }		handle = xsd:string { maxLength="255" pattern="[\-_A-Za-z0-9/]*" }
	uri = xsd:anyURI { maxLength="4096" }		uri = xsd:anyURI { maxLength="4096" }
	any = element * { attribute * { text }*, ( any | text )* }		any = element * { attribute * { text }*, ( any | text )* }
	tag = xsd:token { maxLength="1024" }		tag = xsd:token { maxLength="1024" }
	authorization_token = base64		authorization_token = base64
	bpki_ta = base64		bpki_ta = base64
	start |= element child_request {		start |= element child_request {
End of changes. 70 change blocks.
	112 lines changed or deleted		147 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/