draft-ietf-sidr-rpki-oob-setup-03.txt		draft-ietf-sidr-rpki-oob-setup-04.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 October 19, 2015		Intended status: Standards Track April 11, 2016
	Expires: April 21, 2016		Expires: October 13, 2016
	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-03		draft-ietf-sidr-rpki-oob-setup-04
	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 April 21, 2016.		This Internet-Draft will expire on October 13, 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
	2. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3		2. Overview of the BPKI . . . . . . . . . . . . . . . . . . . . 3
	3. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 4		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 5
	3.2. Common Protocol Elements . . . . . . . . . . . . . . . . 5		4.1. Common Protocol Elements . . . . . . . . . . . . . . . . 5
	3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5		4.2. Protocol Messages . . . . . . . . . . . . . . . . . . . . 6
	3.3.1. <child_request/> . . . . . . . . . . . . . . . . . . 5		4.2.1. <child_request/> . . . . . . . . . . . . . . . . . . 6
	3.3.2. <parent_response/> . . . . . . . . . . . . . . . . . 6		4.2.2. <parent_response/> . . . . . . . . . . . . . . . . . 7
	3.3.3. <publisher_request/> . . . . . . . . . . . . . . . . 8		4.2.3. <publisher_request/> . . . . . . . . . . . . . . . . 9
	3.3.4. <repository_response/> . . . . . . . . . . . . . . . 9		4.2.4. <repository_response/> . . . . . . . . . . . . . . . 10
	3.4. <authorization/> . . . . . . . . . . . . . . . . . . . . 10		4.3. <authorization/> . . . . . . . . . . . . . . . . . . . . 11
	3.5. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 11		4.4. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 12
	4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 12		5. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
	8. Normative References . . . . . . . . . . . . . . . . . . . . 17		9. Normative References . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 18		Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 19
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
	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 4, line 31		skipping to change at page 4, line 31
	Public Key: [Alice CA Public Key]		Public Key: [Alice CA Public Key]
	BasicConstraints: cA = TRUE, pathLenConstraint = 0		BasicConstraints: cA = TRUE, pathLenConstraint = 0
	Later, when Bob receives a CMS message from Alice, Bob can verify		Later, when Bob receives a CMS message from Alice, Bob can verify
	this message via a trust chain back to Bob's own trust anchor:		this message via a trust chain back to Bob's own trust anchor:
	Issuer: CN = Alice CA		Issuer: CN = Alice CA
	Subject: CN = Alice EE		Subject: CN = Alice EE
	Public Key: [Alice EE Public Key]		Public Key: [Alice EE Public Key]
	[[Need some text detailing required and allowed values in the		A complete description of the certificates allowed here is beyond the
	certificates: 2048-bit RSA, what extensions, .... But once we go		scope of this document, as it is determined primarily by what is
	there we also have to provide a path for algorithm agility.]]		acceptable to the several other protocols for which this protocol is
			handling setup. Furthermore, we expect the requirements to change
			over time to track changes in cryptographic algorithms, required key
			length, and so forth. Finally, since this protocol is restricted to
			setting up pairwise relationships, all that's really required is that
			the two parties involved in a particular conversation agree on what
			constitutes an acceptable certificate.
	3. Protocol Elements		All of that said, in practice, the certificates currently exchanged
			by this protocol at the time this document was written are what a
			reader familiar with the technology would probably expect: RSA keys
			with lengths in the 2048-4096 bit range, SHA-2 digests, and a few
			common X.509v3 extensions (principally Basic Constraints, Authority
			Key Identifier, and Subject Key Identifier). Since the most likely
			usage is a cross-certification operation in which the recipient
			simply extracts the Subject Name and public key after checking the
			self-signature and discards the rest of the incoming certificate, the
			practical value of esoteric X.509v3 extensions is somewhat limited.
	Each message in the protocol is a distinct XML element in the		3. Terminology
	"http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.
	3.1. Nomenclature		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
			"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			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
	one protocol or another. Therefore, this note uses its own terms for		one protocol or another. Therefore, this note uses its own terms for
	the actors in this protocol.		the actors in this protocol.
	Child: An entity acting in the client ("subject") role of the		Child: An entity acting in the client ("subject") role of the
	skipping to change at page 5, line 19		skipping to change at page 5, line 36
	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.
	3.2. Common Protocol Elements		4. Protocol Elements
			Each message in the protocol is a distinct XML element in the
			"http://www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.
			4.1. Common Protocol Elements
	The first XML attribute in each message is a version field. This		The first XML attribute in each message is a version field. This
	document describes version 1 of the protocol.		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.
	3.3. Protocol Messages		Most messages allow an optional "tag" attribute. This is an opaque
			cookie supplied by the client in a particular exchange and echoed by
			the server; the intent is to simplify the process of matching a
			response received by the client with an outstanding request.
			4.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.
	3.3.1. <child_request/>		4.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.
	child_handle: The child_handle attribute is what the child calls		child_handle: The child_handle attribute is what the child calls
	itself. This is just a hint from the child to the parent, the		itself. This is just a hint from the child to the parent, the
	parent need not honor it.		parent need not honor it.
	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.
	skipping to change at page 6, line 30		skipping to change at page 7, line 16
	<child_request		<child_request
	child_handle="Bob"		child_handle="Bob"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<child_bpki_ta>		<child_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</child_bpki_ta>		</child_bpki_ta>
	</child_request>		</child_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.3.2. <parent_response/>		4.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.
			tag: If the <child_request/> message included a "tag" attribute, the
			parent MUST include an identical "tag" attribute in the
			<parent_response/> message; if the request did not include a tag
			attribute, the response MUST NOT include a tag attribute either.
	service_uri: The service_uri attribute contains an HTTP URL that the		service_uri: The service_uri attribute contains an HTTP URL that the
	child should contact for up-down ([RFC6492]) service.		child should contact for up-down ([RFC6492]) service.
	child_handle: The child_handle attribute is the parent's name for		child_handle: The child_handle attribute is the parent's name for
	the child. This might or might not match the child_handle from		the child. This MAY match the child_handle from the
	the <child_request/> message. If they do not match, the parent		<child_request/> message. If they do not match, the parent wins,
	wins, because the parent gets to dictate the names in the		because the parent gets to dictate the names in the provisioning
	provisioning protocol. This value is the sender field in		protocol. This value is the sender field in provisioning protocol
	provisioning protocol request messages and the recipient field in		request messages and the recipient field in provisioning protocol
	provisioning protocol response messages.		response messages.
	parent_handle: The parent_handle attribute is the parent's name for		parent_handle: The parent_handle attribute is the parent's name for
	itself. This value is the recipient field in provisioning		itself. This value is the recipient field in provisioning
	protocol request messages and the sender field in provisioning		protocol request messages and the sender field in provisioning
	protocol response messages.		protocol response messages.
	parent_bpki_ta: The <parent_bpki_ta/> element is the parent's BPKI		parent_bpki_ta: The <parent_bpki_ta/> element is the parent's BPKI
	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
	skipping to change at page 7, line 33		skipping to change at page 8, line 25
	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 3.4 for		the publication repository in question. See Section 4.3 for
	details on the authorization token.		details on the authorization token.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Bob-42"		child_handle="Bob-42"
	parent_handle="Alice"		parent_handle="Alice"
	service_uri="http://a.example/up-down/Alice/Bob-42"		service_uri="http://a.example/up-down/Alice/Bob-42"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<parent_bpki_ta>		<parent_bpki_ta>
	skipping to change at page 8, line 21		skipping to change at page 9, line 21
	<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>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.3.3. <publisher_request/>		4.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
			message.
	publisher_handle: The publisher_handle attribute is the publisher's		publisher_handle: The publisher_handle attribute is the publisher's
	name for itself. This is just a hint, the repository need not		name for itself. This is just a hint, the repository need not
	honor it.		honor it.
	publisher_bpki_ta: The <publisher_bpki_ta/> element is the		publisher_bpki_ta: The <publisher_bpki_ta/> element is the
	publisher's BPKI identity, a self-signed X.509 BPKI certificate.		publisher's BPKI 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 publisher will use to sign		corresponding to private keys that the publisher will use to sign
	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 3.4 for details on the		at this repository. See Section 4.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 3.3.2). The		child in the <parent_response/> message (see Section 4.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"		publisher_handle="Bob"
			tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<publisher_bpki_ta>		<publisher_bpki_ta>
	R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=		R29kIGlzIHJlYWwgdW5sZXNzIGRlY2xhcmVkIGludGVnZXI=
	</publisher_bpki_ta>		</publisher_bpki_ta>
	</publisher_request>		</publisher_request>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.3.4. <repository_response/>		4.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,
			the repository MUST include an identical "tag" attribute in the
			<repository_response/> message; if the request did not include a
			tag attribute, the response MUST NOT include a tag attribute
			either.
	service_uri: The service_uri attribute contains an HTTP URL that the		service_uri: The service_uri attribute contains an HTTP URL that the
	publisher should contact for publication service		publisher should contact for publication service
	([I-D.ietf-sidr-publication]).		([I-D.ietf-sidr-publication]).
	publisher_handle: The publisher_handle attribute is the repository's		publisher_handle: The publisher_handle attribute is the repository's
	name for the publisher. This may or may not match the		name for the publisher. This may or may not match the
	publisher_handle attribute in the publisher's <publisher_request/>		publisher_handle attribute in the publisher's <publisher_request/>
	message.		message.
	sia_base: The sia_base attribute is the rsync:// URI for the base of		sia_base: The sia_base attribute is the rsync:// URI for the base of
	skipping to change at page 10, line 11		skipping to change at page 11, line 21
	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"		publisher_handle="Alice/Bob-42"
	rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"		rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"
	service_uri="http://a.example/publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
	sia_base="rsync://a.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/Alice/Bob-42/"
			tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		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>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.4. <authorization/>		4.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
	skipping to change at page 11, line 5		skipping to change at page 12, line 14
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<authorization		<authorization
	authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"		authorized_sia_base="rsync://a.example/rpki/Alice/Bob-42/Carol/"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu		SSd2ZSBoYWQgZnVuIGJlZm9yZS4gIFRoaXMgaXNuJ3QgaXQu
	</authorization>		</authorization>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.5. <error/>		4.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 3.3.		Section 4.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 12, line 19		skipping to change at page 13, line 19
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<child_request		<child_request
	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>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	4. Protocol Walk-Through		5. 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.
	skipping to change at page 13, line 37		skipping to change at page 14, line 37
	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"		publisher_handle="Bob"
			tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<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
	skipping to change at page 14, line 13		skipping to change at page 15, line 13
	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"		publisher_handle="Alice/Bob-42"
	rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"		rrdp_notification_uri="https://rpki.example/rrdp/notify.xml"
	service_uri="http://a.example/publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
	sia_base="rsync://a.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/Alice/Bob-42/"
			tag="A0001"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		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.
	skipping to change at page 16, line 8		skipping to change at page 17, line 8
	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"		publisher_handle="Carol"
			tag="A0002"
	version="1"		version="1"
	xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">		xmlns="http://www.hactrn.net/uris/rpki/rpki-setup/">
	<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>
	skipping to change at page 16, line 33		skipping to change at page 17, line 34
	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"		publisher_handle="Alice/Bob-42/Carol"
	service_uri="http://a.example/publication/Alice/Bob-42/Carol"		service_uri="http://a.example/publication/Alice/Bob-42/Carol"
	sia_base="rsync://a.example/rpki/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/">		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>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	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.
	5. IANA Considerations		6. IANA Considerations
	Blah.		This document makes no request of IANA.
	6. Security Considerations		7. 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.
	7. Acknowledgements		8. 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 whose name the author has temporarily forgotten.		the way but whose name the author has temporarily forgotten.
	8. Normative References		9. 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., Austein, R.,
	and D. Mandelberg, "RPKI Repository Delta Protocol",		and D. Mandelberg, "RPKI Repository Delta Protocol",
	draft-ietf-sidr-delta-protocol-01 (work in progress),		draft-ietf-sidr-delta-protocol-02 (work in progress),
	October 2015.		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-07 (work in		(RPKI)", draft-ietf-sidr-publication-08 (work in
	progress), September 2015.		progress), March 2016.
			[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
			Requirement Levels", RFC 2119, BCP 14, March 1997.
	[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)", 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.
	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 3429 2015-10-14 23:46: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" }
	authorization_token = base64		authorization_token = base64
	bpki_ta = base64		bpki_ta = base64
	start |= element child_request {		start |= element child_request {
	attribute version { version },		attribute version { version },
	attribute child_handle { handle },		attribute child_handle { handle },
			attribute tag { tag }?,
	element child_bpki_ta { bpki_ta }		element child_bpki_ta { bpki_ta }
	}		}
	start |= element parent_response {		start |= element parent_response {
	attribute version { version },		attribute version { version },
	attribute service_uri { uri },		attribute service_uri { uri },
	attribute child_handle { handle },		attribute child_handle { handle },
	attribute parent_handle { handle },		attribute parent_handle { handle },
			attribute tag { tag }?,
	element parent_bpki_ta { bpki_ta },		element parent_bpki_ta { bpki_ta },
	element offer { empty }?,		element offer { empty }?,
	element referral {		element referral {
	attribute referrer { handle },		attribute referrer { handle },
	attribute contact_uri { uri }?,		attribute contact_uri { uri }?,
	authorization_token		authorization_token
	}*		}*
	}		}
	start |= element publisher_request {		start |= element publisher_request {
	attribute version { version },		attribute version { version },
	attribute publisher_handle { handle },		attribute publisher_handle { handle },
			attribute tag { tag }?,
	element publisher_bpki_ta { bpki_ta },		element publisher_bpki_ta { bpki_ta },
	element referral {		element referral {
	attribute referrer { handle },		attribute referrer { handle },
	authorization_token		authorization_token
	}*		}*
	}		}
	start |= element repository_response {		start |= element repository_response {
	attribute version { version },		attribute version { version },
	attribute service_uri { uri },		attribute service_uri { uri },
	attribute publisher_handle { handle },		attribute publisher_handle { handle },
	attribute sia_base { uri },		attribute sia_base { uri },
	attribute rrdp_notification_uri { uri }?,		attribute rrdp_notification_uri { uri }?,
			attribute tag { tag }?,
	element repository_bpki_ta { bpki_ta }		element repository_bpki_ta { bpki_ta }
	}		}
	start |= element authorization {		start |= element authorization {
	attribute version { version },		attribute version { version },
	attribute authorized_sia_base { uri },		attribute authorized_sia_base { uri },
	bpki_ta		bpki_ta
	}		}
	start |= element error {		start |= element error {
End of changes. 50 change blocks.
	63 lines changed or deleted		120 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/