draft-ietf-sidr-publication-11.txt		draft-ietf-sidr-publication-12.txt
	Network Working Group S. Weiler		Network Working Group S. Weiler
	Internet-Draft W3C / MIT		Internet-Draft W3C / MIT
	Intended status: Standards Track A. Sonalker		Intended status: Standards Track A. Sonalker
	Expires: August 21, 2017 TowerSec		Expires: September 12, 2017 TowerSec
	R. Austein		R. Austein
	Dragon Research Labs		Dragon Research Labs
	February 17, 2017		March 11, 2017
	A Publication Protocol for the Resource Public Key Infrastructure (RPKI)		A Publication Protocol for the Resource Public Key Infrastructure (RPKI)
	draft-ietf-sidr-publication-11		draft-ietf-sidr-publication-12
	Abstract		Abstract
	This document defines a protocol for publishing Resource Public Key		This document defines a protocol for publishing Resource Public Key
	Infrastructure (RPKI) objects. Even though the RPKI will have many		Infrastructure (RPKI) objects. Even though the RPKI will have many
	participants issuing certificates and creating other objects, it is		participants issuing certificates and creating other objects, it is
	operationally useful to consolidate the publication of those objects.		operationally useful to consolidate the publication of those objects.
	Even in cases where a certificate issuer runs their own publication		Even in cases where a certificate issuer runs their own publication
	repository, it can be useful to run the certificate engine itself on		repository, it can be useful to run the certificate engine itself on
	a different machine from the publication repository. This document		a different machine from the publication repository. This document
	skipping to change at page 1, line 40		skipping to change at page 1, line 40
	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 August 21, 2017.		This Internet-Draft will expire on September 12, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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
	skipping to change at page 5, line 19		skipping to change at page 5, line 19
	"Business Public Key Infrastructure" ("Business PKI" or "BPKI")		"Business Public Key Infrastructure" ("Business PKI" or "BPKI")
	refers to a PKI, separate from the RPKI, used to authenticate clients		refers to a PKI, separate from the RPKI, used to authenticate clients
	to the publication engine. We use the term "Business PKI" here		to the publication engine. We use the term "Business PKI" here
	because an Internet registry might already have a PKI for		because an Internet registry might already have a PKI for
	authenticating its clients and might wish to reuse that PKI for this		authenticating its clients and might wish to reuse that PKI for this
	protocol. There is, however, no requirement to reuse such a PKI.		protocol. There is, however, no requirement to reuse such a PKI.
	2. Protocol Specification		2. Protocol Specification
	The publication protocol uses XML ([XML]) messages wrapped in signed		The publication protocol uses XML ([XML]) messages wrapped in signed
	CMS messages, carried over HTTP transport ([RFC2616]). The CMS		CMS messages, carried over HTTP transport ([RFC7230]). The CMS
	encapsulation is identical to that used in [RFC6492], section 3.1 and		encapsulation is identical to that used in [RFC6492], section 3.1 and
	subsections.		subsections.
	The publication protocol uses a simple request/response interaction.		The publication protocol uses a simple request/response interaction.
	The client passes a request to the server, and the server generates a		The client passes a request to the server, and the server generates a
	corresponding response.		corresponding response.
	A message exchange commences with the client initiating an HTTP POST		A message exchange commences with the client initiating an HTTP POST
	with content type of "application/rpki-publication", with the message		with content type of "application/rpki-publication", with the message
	object as the body. The server's response will similarly be the body		object as the body. The server's response will similarly be the body
	skipping to change at page 6, line 52		skipping to change at page 6, line 52
	tagging MAY use any syntactically legal value, including simply using		tagging MAY use any syntactically legal value, including simply using
	the empty string for all tag fields.		the empty string for all tag fields.
	This document describes version 4 of this protocol. An		This document describes version 4 of this protocol. An
	implementation which understands only this version of the protocol		implementation which understands only this version of the protocol
	MUST reject messages with a different protocol version attribute,		MUST reject messages with a different protocol version attribute,
	signalling the error as described in Section 2.4. Since "4" is		signalling the error as described in Section 2.4. Since "4" is
	currently the only value allowed for the version attribute in the		currently the only value allowed for the version attribute in the
	schema (Section 2.6), an incorrect protocol version can be detected		schema (Section 2.6), an incorrect protocol version can be detected
	either by checking the version attribute directly or as a schema		either by checking the version attribute directly or as a schema
	validation error.		validation error. Any future update to this protocol which is either
			syntactically or semantically incompatible with the current version
			will need to increment the protocol version number.
	2.2. Publication and Withdrawal		2.2. Publication and Withdrawal
	The publication protocol uses a common message format to request		The publication protocol uses a common message format to request
	publication of any RPKI object. This format was chosen specifically		publication of any RPKI object. This format was chosen specifically
	to allow this protocol to accommodate new types of RPKI objects		to allow this protocol to accommodate new types of RPKI objects
	without needing changes to this protocol.		without needing changes to this protocol.
	Both the <publish/> and <withdraw/> PDUs have a payload of a tag and		Both the <publish/> and <withdraw/> PDUs have a payload of a tag and
	an rsync URI ([RFC3986], [RFC5781]). The <publish/> query also		an rsync URI ([RFC3986], [RFC5781]). The <publish/> query also
	skipping to change at page 18, line 39		skipping to change at page 18, line 39
	7.1. Normative References		7.1. Normative References
	[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.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", RFC 3986,		Resource Identifier (URI): Generic Syntax", RFC 3986,
	STD 66, January 2005.		STD 66, January 2005.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[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.
	[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI		[RFC5781] Weiler, S., Ward, D., and R. Housley, "The rsync URI
	Scheme", RFC 5781, February 2010.		Scheme", RFC 5781, February 2010.
	[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.
	[SHS] National Institute of Standards and Technology, "Secure		[SHS] National Institute of Standards and Technology, "Secure
	Hash Standard", FIPS PUB 180-4, March 2012,		Hash Standard", FIPS PUB 180-4, March 2012,
	<http://csrc.nist.gov/publications/fips/fips180-4/		<http://csrc.nist.gov/publications/fips/fips180-4/
	fips-180-4.pdf>.		fips-180-4.pdf>.
	[XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR		[XML] Cowan, J., "Extensible Markup Language (XML) 1.1", W3C CR
	CR-xml11-20021015, October 2002.		CR-xml11-20021015, October 2002.
	7.2. Informative References		7.2. Informative References
	[I-D.ietf-sidr-delta-protocol]		[I-D.ietf-sidr-delta-protocol]
	Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,		Bruijnzeels, T., Muravskiy, O., Weber, B., and R. Austein,
	"RPKI Repository Delta Protocol", draft-ietf-sidr-delta-		"RPKI Repository Delta Protocol", draft-ietf-sidr-delta-
	protocol-07 (work in progress), February 2017.		protocol-07 (work in progress), February 2017.
	[I-D.ietf-sidr-rpki-oob-setup]		[I-D.ietf-sidr-rpki-oob-setup]
	Austein, R., "An Out-Of-Band Setup Protocol For RPKI		Austein, R., "An Out-Of-Band Setup Protocol For RPKI
	Production Services", draft-ietf-sidr-rpki-oob-setup-06		Production Services", draft-ietf-sidr-rpki-oob-setup-09
	(work in progress), January 2017.		(work in progress), February 2017.
	[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support		[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
	Secure Internet Routing", RFC 6480, February 2012.		Secure Internet Routing", RFC 6480, February 2012.
	Authors' Addresses		Authors' Addresses
	Samuel Weiler		Samuel Weiler
	W3C / MIT		W3C / MIT
	Email: weiler@csail.mit.edu		Email: weiler@csail.mit.edu
End of changes. 9 change blocks.
	12 lines changed or deleted		14 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/