draft-ietf-sidr-rpki-oob-setup-08.txt		draft-ietf-sidr-rpki-oob-setup-09.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 February 22, 2017		Intended status: Standards Track February 22, 2017
	Expires: August 26, 2017		Expires: August 26, 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-08		draft-ietf-sidr-rpki-oob-setup-09
	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 means which		be passed back and forth by any mutually agreeable means which
	provides acceptable data integrity and authentication.		provides acceptable data integrity and authentication.
	This setup protocol is not part of the provisioning or publication		This setup protocol is not part of the provisioning or publication
	skipping to change at page 6, line 26		skipping to change at page 6, line 26
	Since "1" is currently the only value allowed for the version		Since "1" is currently the only value allowed for the version
	attribute in the schema, an incorrect protocol version can be		attribute in the schema, an incorrect protocol version can be
	detected either by checking the version attribute directly or as a		detected either by checking the version attribute directly or as a
	schema validation error.		schema validation error.
	5.1. Common Protocol Elements		5.1. Common Protocol Elements
	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 ([RFC4648] section 4, with line
	of the X.509 certificate.		breaks within the Base64 text permitted but not required) encoding
			the DER representation 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.
	skipping to change at page 8, line 7		skipping to change at page 8, line 7
	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		tag: If the <child_request/> message included a "tag" attribute, the
	parent MUST include an identical "tag" attribute in the		parent MUST include an identical "tag" attribute in the
	<parent_response/> message; if the request did not include a tag		<parent_response/> message; if the request did not include a tag
	attribute, the response MUST NOT include a tag attribute either.		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 or HTTPS URL
	child should contact for up-down ([RFC6492]) service.		([RFC7230]) that the 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 MAY match the child_handle from the		the child. This MAY match the child_handle from the
	<child_request/> message. If they do not match, the parent wins,		<child_request/> message. If they do not match, the parent wins,
	because the parent gets to dictate the names in the provisioning		because the parent gets to dictate the names in the provisioning
	protocol. This value is the sender field in provisioning protocol		protocol. This value is the sender field in provisioning protocol
	request messages and the recipient field in provisioning protocol		request messages and the recipient field in 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
	skipping to change at page 11, line 21		skipping to change at page 11, line 21
	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,
	the repository MUST include an identical "tag" attribute in the		the repository MUST include an identical "tag" attribute in the
	<repository_response/> message; if the request did not include a		<repository_response/> message; if the request did not include a
	tag attribute, the response MUST NOT include a tag attribute		tag attribute, the response MUST NOT include a tag attribute
	either.		either.
	service_uri: The service_uri attribute contains an HTTP URL that the		service_uri: The service_uri attribute contains an HTTP or HTTPS URL
	publisher should contact for publication service		([RFC7230]) that the publisher should contact for publication
	([I-D.ietf-sidr-publication]).		service ([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
	the publication space allocated to the publisher.		the publication space allocated to the publisher.
	rrdp_notification_uri: The optional rrdp_notification_uri attribute		rrdp_notification_uri: The optional rrdp_notification_uri attribute
	skipping to change at page 12, line 26		skipping to change at page 12, line 26
	</repository_bpki_ta>		</repository_bpki_ta>
	</repository_response>		</repository_response>
	---------------------------------------------------------------------		---------------------------------------------------------------------
	5.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 ([RFC6492]).
	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.
	skipping to change at page 20, line 5		skipping to change at page 20, line 5
	(RPKI)", draft-ietf-sidr-publication-11 (work in		(RPKI)", draft-ietf-sidr-publication-11 (work in
	progress), February 2017.		progress), February 2017.
	[RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November		[RelaxNG] Clark, J., "RELAX NG Compact Syntax", OASIS , November
	2002, <https://www.oasis-open.org/committees/relax-ng/		2002, <https://www.oasis-open.org/committees/relax-ng/
	compact-20021121.html>.		compact-20021121.html>.
	[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.
			[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
			Encodings", RFC 4648, October 2006.
	[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A		[RFC6492] Huston, G., Loomans, R., Ellacott, B., and R. Austein, "A
	Protocol for Provisioning Resource Certificates",		Protocol for Provisioning Resource Certificates",
	RFC 6492, February 2012.		RFC 6492, February 2012.
			[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
			(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
			2014.
	10.2. Informative References		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.
End of changes. 7 change blocks.
	9 lines changed or deleted		18 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/