draft-ietf-sidr-rpki-oob-setup-00.txt		draft-ietf-sidr-rpki-oob-setup-01.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 December 11, 2013		Intended status: Standards Track July 2, 2014
	Expires: June 14, 2014		Expires: January 3, 2015
	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-00		draft-ietf-sidr-rpki-oob-setup-01
	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 June 14, 2014.		This Internet-Draft will expire on January 3, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 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. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 4
	3.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Nomenclature . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Common Protocol Elements . . . . . . . . . . . . . . . . 5		3.2. Common Protocol Elements . . . . . . . . . . . . . . . . 5
	3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5		3.3. Protocol Messages . . . . . . . . . . . . . . . . . . . . 5
	3.3.1. <child_request/> . . . . . . . . . . . . . . . . . . 6		3.3.1. <child_request/> . . . . . . . . . . . . . . . . . . 5
	3.3.2. <parent_response/> . . . . . . . . . . . . . . . . . 6		3.3.2. <parent_response/> . . . . . . . . . . . . . . . . . 6
	3.3.3. <publisher_request/> . . . . . . . . . . . . . . . . 8		3.3.3. <publisher_request/> . . . . . . . . . . . . . . . . 8
	3.3.4. <repository_response/> . . . . . . . . . . . . . . . 9		3.3.4. <repository_response/> . . . . . . . . . . . . . . . 9
	3.4. <authorization/> . . . . . . . . . . . . . . . . . . . . 10		3.4. <authorization/> . . . . . . . . . . . . . . . . . . . . 10
	3.5. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 11		3.5. <error/> . . . . . . . . . . . . . . . . . . . . . . . . 11
	4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 12		4. Protocol Walk-Through . . . . . . . . . . . . . . . . . . . . 12
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 16		6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
	8. Normative References . . . . . . . . . . . . . . . . . . . . 17		8. Normative References . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 17		Appendix A. RelaxNG Schema . . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
	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
	skipping to change at page 3, line 10		skipping to change at page 3, line 10
	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. Overview of the BPKI
	Several protocols related to RPKI provisioning use signed CMS		Several protocols related to RPKI provisioning use signed CMS
	messages to authenticate the underlying XML-based protocols.		messages ([RFC5652]) to authenticate the underlying XML-based
	Verification of these CMS messages requires X.509 certificates. The		protocols. Verification of these CMS messages requires X.509
	PKI that holds these certificates is distinct from the RPKI, and		certificates. The PKI that holds these certificates is distinct from
	contains no RFC 3779 resources. We refer to this as the "Business		the RPKI, and contains no RFC 3779 resources. We refer to this as
	PKI" (BPKI), to distinguish it from the RPKI. The "B" is a hint that		the "Business PKI" (BPKI), to distinguish it from the RPKI. The "B"
	the certificate relationships in the BPKI are likely to follow and		is a hint that the certificate relationships in the BPKI are likely
	become part of existing contractual relationships between the issuers		to follow and become part of existing contractual relationships
	and subjects of this PKI.		between the issuers and subjects of this PKI.
	The RPKI provisioning protocol does not dictate a particular		The RPKI provisioning protocol does not dictate a particular
	structure for the BPKI, beyond the basic requirement that it be		structure for the BPKI, beyond the basic requirement that it be
	possible for one party to sign and the other party to verify the CMS		possible for one party to sign and the other party to verify the CMS
	messages. This allows a certain amount of flexibility to allow an		messages. This allows a certain amount of flexibility to allow an
	Internet registry to reuse an existing PKI as the BPKI if that makes		Internet registry to reuse an existing PKI as the BPKI if that makes
	sense in their context.		sense in their context.
	In order to keep this protocol simple, we adopt a somewhat		In order to keep this protocol simple, we adopt a somewhat
	constrained model of the BPKI. The first two operations in this		constrained model of the BPKI. The first two operations in this
	skipping to change at page 4, line 19		skipping to change at page 4, line 19
	Issuer: CN = Bob CA		Issuer: CN = Bob CA
	Subject: CN = Bob CA		Subject: CN = Bob CA
	Public Key: [Bob CA Public Key]		Public Key: [Bob CA Public Key]
	BasicConstraints: cA = TRUE		BasicConstraints: cA = TRUE
	Alice sends Bob her self-signed BPKI certificate, and Bob cross-		Alice sends Bob her self-signed BPKI certificate, and Bob cross-
	certifies its public key and subject name under Bob's own self-signed		certifies its public key and subject name under Bob's own self-signed
	BPKI certificate:		BPKI certificate:
	Issuer: CN = Bob CA		Issuer: CN = Bob CA
	Subject: CN = Alice CA		Subject: CN = Alice CA
	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		[[Need some text detailing required and allowed values in the
	certificates: 2048-bit RSA, what extensions, .... But once we go		certificates: 2048-bit RSA, what extensions, .... But once we go
	there we also have to provide a path for algorithm agility.]]		there we also have to provide a path for algorithm agility.]]
	3. Protocol Elements		3. Protocol Elements
	Each message in the protocol is a distinct XML element in the "http:/		Each message in the protocol is a distinct XML element in the "http:/
	/www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.		/www.hactrn.net/uris/rpki/rpki-setup/" XML namespace.
	skipping to change at page 7, line 33		skipping to change at page 7, line 25
	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 a <referral/> element is present, it suggests a third-
	party publication services that the child might use, and contains:		party publication services that the child might use, and contains:
	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		child the right to use a portion of the parent's namespace at
	at the publication repository in question. See Section 3.4		the publication repository in question. See Section 3.4 for
	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://alice.example/rpki-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>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</parent_bpki_ta>		</parent_bpki_ta>
	<offer/>		<offer/>
	</parent_response>		</parent_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<parent_response		<parent_response
	child_handle="Carol"		child_handle="Carol"
	parent_handle="Bob"		parent_handle="Bob"
	service_uri="http://bob.example/rpki-up-down/Bob/Carol"		service_uri="http://bob.example/up-down/Bob/Carol"
	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>
	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 8, line 50		skipping to change at page 8, line 44
	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		publisher the right to use a portion of its parent's namespace
	namespace at this repository. See Section 3.4 for details		at this repository. See Section 3.4 for details on the
	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 3.3.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.
	skipping to change at page 10, line 11		skipping to change at page 10, line 8
	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
	the publication space allocated to the publisher.		the publication space allocated to the publisher.
	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"
	service_uri="http://alice.example/rpki-publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
	sia_base="rsync://alice.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/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/">
	<repository_bpki_ta>		<repository_bpki_ta>
	WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU		WW91IGNhbiBoYWNrIGFueXRoaW5nIHlvdSB3YW50IHdpdGggVEVDTyBhbmQgRERU
	</repository_bpki_ta>		</repository_bpki_ta>
	</repository_response>		</repository_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	3.4. <authorization/>		3.4. <authorization/>
	skipping to change at page 10, line 45		skipping to change at page 10, line 42
	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 <bpki_ta/> element is the identity of the entity to
	whom the referrer is delegating the portion of the namespace named		whom the referrer is delegating the portion of the namespace named
	in the authorized_sia_base attribute. The identity is represented		in the authorized_sia_base attribute. The identity is represented
	as a self-signed X.509 BPKI certificate.		as a self-signed X.509 BPKI certificate.
	---------------------------------------------------------------------		---------------------------------------------------------------------
	<authorization		<authorization
	authorized_sia_base="rsync://alice.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/>		3.5. <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
	skipping to change at page 11, line 36		skipping to change at page 11, line 36
	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.
	reason: The reason attribute contains a code indicating what was		reason: The reason attribute contains a code indicating what was
	wrong with the message. This version of the protocol defines the		wrong with the message. This version of the protocol defines the
	following codes:		following codes:
	syntax-error: Receiver could not parse the offending message.		syntax-error: Receiver could not parse the offending message.
	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"		reason="refused"
	version="1"		version="1"
	skipping to change at page 13, line 9		skipping to change at page 13, line 16
	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"		child_handle="Bob-42"
	parent_handle="Alice"		parent_handle="Alice"
	service_uri="http://alice.example/rpki-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>
	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.
	skipping to change at page 13, line 50		skipping to change at page 14, line 10
	<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"		publisher_handle="Alice/Bob-42"
	service_uri="http://alice.example/rpki-publication/Alice/Bob-42"		service_uri="http://a.example/publication/Alice/Bob-42"
	sia_base="rsync://alice.example/rpki/Alice/Bob-42/"		sia_base="rsync://a.example/rpki/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/">
	<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 14, line 46		skipping to change at page 15, line 9
	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"		child_handle="Carol"
	parent_handle="Bob"		parent_handle="Bob"
	service_uri="http://bob.example/rpki-up-down/Bob/Carol"		service_uri="http://bob.example/up-down/Bob/Carol"
	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>
	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 15, line 25		skipping to change at page 15, line 34
	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://alice.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>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	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
	skipping to change at page 16, line 19		skipping to change at page 16, line 31
	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"		publisher_handle="Alice/Bob-42/Carol"
	service_uri="http://alice.example/rpki-publication/Alice/Bob-42/Carol"		service_uri="http://a.example/publication/Alice/Bob-42/Carol"
	sia_base="rsync://alice.example/rpki/Alice/Bob-42/Carol/"		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/">
	<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.
	skipping to change at page 17, line 17		skipping to change at page 17, line 28
	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 whose name the author has temporarily forgotten.
	8. Normative References		8. Normative References
	[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-04 (work in		(RPKI)", draft-ietf-sidr-publication-05 (work in
	progress), October 2013.		progress), February 2014.
	[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)", RFC
	5652, STD 70, September 2009.		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
End of changes. 27 change blocks.
	51 lines changed or deleted		49 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/