< draft-ietf-sidr-rpsl-sig-09.txt		draft-ietf-sidr-rpsl-sig-10.txt >
	SIDR R. Kisteleki		SIDR R. Kisteleki
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Intended status: Standards Track B. Haberman		Updates: 2622, 4012 (if approved) B. Haberman
	Expires: September 4, 2016 JHU APL		Intended status: Standards Track JHU APL
	March 3, 2016		Expires: September 11, 2016 March 10, 2016
	Securing RPSL Objects with RPKI Signatures		Securing RPSL Objects with RPKI Signatures
	draft-ietf-sidr-rpsl-sig-09.txt		draft-ietf-sidr-rpsl-sig-10.txt
	Abstract		Abstract
	This document describes a method to allow parties to electronically		This document describes a method to allow parties to electronically
	sign RPSL-like objects and validate such electronic signatures. This		sign Routing Policy Specification Language objects and validate such
	allows relying parties to detect accidental or malicious		electronic signatures. This allows relying parties to detect
	modifications on such objects. It also allows parties who run		accidental or malicious modifications on such objects. It also
	Internet Routing Registries or similar databases, but do not yet have		allows parties who run Internet Routing Registries or similar
	RPSS-like authentication of the maintainers of certain objects, to		databases, but do not yet have Routing Policy System Security-based
	verify that the additions or modifications of such database objects		authentication of the maintainers of certain objects, to verify that
	are done by the legitimate holder(s) of the Internet resources		the additions or modifications of such database objects are done by
	mentioned in those objects.		the legitimate holder(s) of the Internet resources mentioned in those
			objects. This document updates RFC 2622 and RFC 4012 to add the
			signature attribute to supported RPSL objects.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 September 4, 2016.		This Internet-Draft will expire on September 11, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 39 ¶		skipping to change at page 2, line 41 ¶
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	Objects stored in resource databases, like the RIPE DB, are generally		Objects stored in resource databases, like the RIPE DB, are generally
	protected by an authentication mechanism: anyone creating or		protected by an authentication mechanism: anyone creating or
	modifying an object in the database has to have proper authorization		modifying an object in the database has to have proper authorization
	to do so, and therefore has to go through an authentication procedure		to do so, and therefore has to go through an authentication procedure
	(provide a password, certificate, e-mail signature, etc.) However,		(provide a password, certificate, e-mail signature, etc.) However,
	for objects transferred between resource databases, the		for objects transferred between resource databases, the
	authentication is not guaranteed. This means when downloading an		authentication is not guaranteed. This means when downloading a
	object stored in this database, one can reasonably safely claim that		Routing Policy Specification Language (RPSL) object stored in this
	the object is authentic, but for an imported object one cannot.		database, one can reasonably safely claim that the object is
	Also, once such an object is downloaded from the database, it becomes		authentic, but for an imported object one cannot. Also, once such an
	a simple (but still structured) text file with no integrity		object is downloaded from the database, it becomes a simple (but
	protection. More importantly, the authentication and integrity		still structured) text file with no integrity protection. More
	guarantees associated with these objects do not always ensure that		importantly, the authentication and integrity guarantees associated
	the entity that generated them is authorized to make the assertions		with these objects do not always ensure that the entity that
	implied by the data contained in the objects.		generated them is authorized to make the assertions implied by the
			data contained in the objects.
	A potential use for resource certificates [RFC6487] is to use them to		A potential use for resource certificates [RFC6487] is to use them to
	secure such (both imported and downloaded) database objects, by		secure such (both imported and downloaded) database objects, by
	applying a form of digital signature over the object contents. A		applying a digital signature over the object contents. A maintainer
	maintainer of such signed database objects MUST possess a relevant		of such signed database objects MUST possess a relevant resource
	resource certificate, which shows him/her as the legitimate holder of		certificate, which shows him/her as the legitimate holder of an
	an Internet number resource. This mechanism allows the users of such		Internet number resource. This mechanism allows the users of such
	database objects to verify that the contents are in fact produced by		database objects to verify that the contents are in fact produced by
	the legitimate holder(s) of the Internet resources mentioned in those		the legitimate holder(s) of the Internet resources mentioned in those
	objects. It also allows the signatures to cover whole RPSL objects,		objects. It also allows the signatures to cover whole RPSL objects,
	or just selected attributes of them. In other words, a digital		or just selected attributes of them. In other words, a digital
	signature created using the private key associated with a resource		signature created using the private key associated with a resource
	certificate can offer object security in addition to the channel		certificate can offer object security in addition to the channel
	security already present in most of such databases. Object security		security already present in most of such databases. Object security
	in turn allows such objects to be hosted in different databases and		in turn allows such objects to be hosted in different databases and
	still be independently verifiable.		still be independently verifiable.
	The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",		The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
	"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	2. Signature Syntax and Semantics		2. Signature Syntax and Semantics
	When signing an RPSL object, the input for the signature process is		When signing an RPSL object [RFC2622][RFC4012], the input for the
	transformed into a sequence of strings of (ASCII) data. The approach		signature process is transformed into a sequence of strings of
	is similar to the one used in DKIM (Domain Key Identified Mail)		(ASCII) data. The approach is similar to the one used in DKIM
	[RFC4871]. In the case of RPSL, the object-to-be-signed closely		(Domain Key Identified Mail) [RFC6376]. In the case of RPSL, the
	resembles an SMTP header, so it seems reasonable to adapt DKIM's		object-to-be-signed closely resembles an SMTP header, so it seems
	relevant features.		reasonable to adapt DKIM's relevant features.
	2.1. General Attributes, Meta Information		2.1. General Attributes, Meta Information
	The digital signature associated with an RPSL object is itself a new		The digital signature associated with an RPSL object is itself a new
	attribute named "signature". It consists of mandatory and optional		attribute named "signature". It consists of mandatory and optional
	fields. These fields are structured in a sequence of name and value		fields. These fields are structured in a sequence of name and value
	pairs, separated by a semicolon ";" and a white space. Collectively		pairs, separated by a semicolon ";" and a white space. Collectively
	these fields make up the value for the new "signature" attribute.		these fields make up the value for the new "signature" attribute.
	The "name" part of such a component is always a single ASCII		The "name" part of such a component is always a single ASCII
	character that serves as an identifier; the value is an ASCII string		character that serves as an identifier; the value is an ASCII string
	skipping to change at page 13, line 33 ¶		skipping to change at page 13, line 33 ¶
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	<http://www.rfc-editor.org/info/rfc3339>.		<http://www.rfc-editor.org/info/rfc3339>.
	[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP		[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP
	Addresses and AS Identifiers", RFC 3779,		Addresses and AS Identifiers", RFC 3779,
	DOI 10.17487/RFC3779, June 2004,		DOI 10.17487/RFC3779, June 2004,
	<http://www.rfc-editor.org/info/rfc3779>.		<http://www.rfc-editor.org/info/rfc3779>.
			[RFC4012] Blunk, L., Damas, J., Parent, F., and A. Robachevsky,
			"Routing Policy Specification Language next generation
			(RPSLng)", RFC 4012, DOI 10.17487/RFC4012, March 2005,
			<http://www.rfc-editor.org/info/rfc4012>.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
	Algorithms and Identifiers for RSA Cryptography for use in		Algorithms and Identifiers for RSA Cryptography for use in
	the Internet X.509 Public Key Infrastructure Certificate		the Internet X.509 Public Key Infrastructure Certificate
	and Certificate Revocation List (CRL) Profile", RFC 4055,		and Certificate Revocation List (CRL) Profile", RFC 4055,
	DOI 10.17487/RFC4055, June 2005,		DOI 10.17487/RFC4055, June 2005,
	<http://www.rfc-editor.org/info/rfc4055>.		<http://www.rfc-editor.org/info/rfc4055>.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
	2006, <http://www.rfc-editor.org/info/rfc4632>.		2006, <http://www.rfc-editor.org/info/rfc4632>.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
	<http://www.rfc-editor.org/info/rfc4648>.		<http://www.rfc-editor.org/info/rfc4648>.
	[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
	J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
	Signatures", RFC 4871, DOI 10.17487/RFC4871, May 2007,
	<http://www.rfc-editor.org/info/rfc4871>.
	[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of		[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of
	Autonomous System (AS) Numbers", RFC 5396,		Autonomous System (AS) Numbers", RFC 5396,
	DOI 10.17487/RFC5396, December 2008,		DOI 10.17487/RFC5396, December 2008,
	<http://www.rfc-editor.org/info/rfc5396>.		<http://www.rfc-editor.org/info/rfc5396>.
	[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6		[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
	Address Text Representation", RFC 5952,		Address Text Representation", RFC 5952,
	DOI 10.17487/RFC5952, August 2010,		DOI 10.17487/RFC5952, August 2010,
	<http://www.rfc-editor.org/info/rfc5952>.		<http://www.rfc-editor.org/info/rfc5952>.
			[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
			"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
			RFC 6376, DOI 10.17487/RFC6376, September 2011,
			<http://www.rfc-editor.org/info/rfc6376>.
	[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for		[RFC6481] Huston, G., Loomans, R., and G. Michaelson, "A Profile for
	Resource Certificate Repository Structure", RFC 6481,		Resource Certificate Repository Structure", RFC 6481,
	DOI 10.17487/RFC6481, February 2012,		DOI 10.17487/RFC6481, February 2012,
	<http://www.rfc-editor.org/info/rfc6481>.		<http://www.rfc-editor.org/info/rfc6481>.
	[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for		[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for
	X.509 PKIX Resource Certificates", RFC 6487,		X.509 PKIX Resource Certificates", RFC 6487,
	DOI 10.17487/RFC6487, February 2012,		DOI 10.17487/RFC6487, February 2012,
	<http://www.rfc-editor.org/info/rfc6487>.		<http://www.rfc-editor.org/info/rfc6487>.
End of changes. 10 change blocks.
	37 lines changed or deleted		45 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/