< draft-ietf-sidr-rpsl-sig-08.txt		draft-ietf-sidr-rpsl-sig-09.txt >
	SIDR R. Kisteleki		SIDR R. Kisteleki
	Internet-Draft RIPE NCC		Internet-Draft RIPE NCC
	Intended status: Standards Track B. Haberman		Intended status: Standards Track B. Haberman
	Expires: April 11, 2016 JHU APL		Expires: September 4, 2016 JHU APL
	October 9, 2015		March 3, 2016
	Securing RPSL Objects with RPKI Signatures		Securing RPSL Objects with RPKI Signatures
	draft-ietf-sidr-rpsl-sig-08.txt		draft-ietf-sidr-rpsl-sig-09.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 RPSL-like objects and validate such electronic signatures. This
	allows relying parties to detect accidental or malicious		allows relying parties to detect accidental or malicious
	modifications on such objects. It also allows parties who run		modifications on such objects. It also allows parties who run
	Internet Routing Registries or similar databases, but do not yet have		Internet Routing Registries or similar databases, but do not yet have
	RPSS-like authentication of the maintainers of certain objects, to		RPSS-like authentication of the maintainers of certain objects, to
	verify that the additions or modifications of such database objects		verify that the additions or modifications of such database objects
	skipping to change at page 1, line 39 ¶		skipping to change at page 1, line 39 ¶
	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 11, 2016.		This Internet-Draft will expire on September 4, 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. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3		2. Signature Syntax and Semantics . . . . . . . . . . . . . . . 3
	2.1. General Attributes, Meta Information . . . . . . . . . . 3		2.1. General Attributes, Meta Information . . . . . . . . . . 3
	2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 4		2.2. Signed Attributes . . . . . . . . . . . . . . . . . . . . 5
	2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5		2.3. Storage of the Signature Data . . . . . . . . . . . . . . 5
	2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5		2.4. Number Resource Coverage . . . . . . . . . . . . . . . . 5
	2.5. Validity Time of the Signature . . . . . . . . . . . . . 6		2.5. Validity Time of the Signature . . . . . . . . . . . . . 6
	3. Signature Creation and Validation Steps . . . . . . . . . . . 6		3. Signature Creation and Validation Steps . . . . . . . . . . . 6
	3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6		3.1. Canonicalization . . . . . . . . . . . . . . . . . . . . 6
	3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8		3.2. Signature Creation . . . . . . . . . . . . . . . . . . . 8
	3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9		3.3. Signature Validation . . . . . . . . . . . . . . . . . . 9
	4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10		4. Signed Object Types, Set of Signed Attributes . . . . . . . . 10
	5. Keys and Certificates used for Signature and Verification . . 12		5. Keys and Certificates used for Signature and Verification . . 12
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
	9. Normative References . . . . . . . . . . . . . . . . . . . . 13		9. Normative References . . . . . . . . . . . . . . . . . . . . 13
	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,
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	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
	the contents of which depend on the field type. Mandatory fields		the contents of which depend on the field type. Mandatory fields
	must appear exactly once, whereas optional fields MUST appear at most		must appear exactly once, whereas optional fields MUST appear at most
	once.		once.
	Mandatory fields of the "signature" attribute:		Mandatory fields of the "signature" attribute:
	o Version number of the signature (field "v"). This field MUST be		o Version of the signature (field "v"). This field MUST be set to
	set to "1".		"rpkiv1". The signature format described in this document applies
			when the version field is set to "rpkiv1". All the rest of the
			signature attributes are defined by the value of version field.
	o Reference to the certificate corresponding to the private key used		o Reference to the certificate corresponding to the private key used
	to sign this object (field "c"). This is a URL of type "rsync" or		to sign this object (field "c"). The value of this field MUST be
	"http(s)" that points to a specific resource certificate in an		a URL of type "rsync" or "http(s)" that points to a specific
	RPKI repository [RFC6481]. The value of this field MUST be an		resource certificate in an RPKI repository [RFC6481]. Any non
	"rsync://..." or an "http[s]://..." URL. Any non URL-safe		URL-safe characters (including semicolon ";" and plus "+") must be
	characters (including semicolon ";" and plus "+") must be URL		URL encoded.
	encoded.
	o Signature method (field "m"): what hash and signature algorithms		o Signature method (field "m"): what hash and signature algorithms
	were used to create the signature. The allowed algorithms which		were used to create the signature. The allowed algorithms which
	can be used for the signature are specified in [RFC6485].		can be used for the signature are specified in Section 5 of RFC
			4055 [RFC4055]. More specifically, this version of RPSL
			signatures supports the following hash algorithms:
			* sha224WithRSAEncryption
			* sha256WithRSAEncryption
			* sha384WithRSAEncryption
			* sha512WithRSAEncryption
			The algorithms are referenced witin the signature attribute by the
			ASCII names of the algorithms.
	o Time of signing (field "t"). The format of the value of this		o Time of signing (field "t"). The format of the value of this
	field MUST be in the Internet Date/Time format [RFC3339]. All		field MUST be in the Internet Date/Time format [RFC3339]. All
	times MUST be converted to Universal Coordinated Time (UTC)		times MUST be converted to Universal Coordinated Time (UTC)
	o The signed attributes (field "a"). This is a list of attribute		o The signed attributes (field "a"). This is a list of attribute
	names, separated by an ASCII "+" character (if more than one		names, separated by an ASCII "+" character (if more than one
	attribute is enumerated). The list must include any attribute at		attribute is enumerated). The list must include any attribute at
	most once.		most once.
	skipping to change at page 5, line 32 ¶		skipping to change at page 5, line 42 ¶
	2.3. Storage of the Signature Data		2.3. Storage of the Signature Data
	The result of applying the signature mechanism once is exactly one		The result of applying the signature mechanism once is exactly one
	new attribute for the object. As an illustration, the structure of a		new attribute for the object. As an illustration, the structure of a
	signed RPSL object is as follows:		signed RPSL object is as follows:
	attribute1: value1		attribute1: value1
	attribute2: value2		attribute2: value2
	attribute3: value3		attribute3: value3
	...		...
	signature: v=1; c=rsync://.....; m=sha256WithRSAEncryption;		signature: v=rpkiv1; c=rsync://.....; m=sha256WithRSAEncryption;
	t=2014-12-31T23:59:60Z;		t=2014-12-31T23:59:60Z;
	a=attribute1+attribute2+attribute3+...;		a=attribute1+attribute2+attribute3+...;
	b=<base64 data>		b=<base64 data>
	2.4. Number Resource Coverage		2.4. Number Resource Coverage
	Even if the signature(s) over the object are valid according to the		Even if the signature(s) over the object are valid according to the
	signature validation rules, they may not be relevant to the object;		signature validation rules, they may not be relevant to the object;
	they also need to cover the relevant Internet number resources		they also need to cover the relevant Internet number resources
	mentioned in the object.		mentioned in the object.
	Therefore the Internet number resources present in [RFC3779]		Therefore the Internet number resources present in [RFC3779]
	extensions of the certificate referred to in the "c" field of the		extensions of the certificate referred to in the "c" field of the
	signature (or in the union of such extensions in the "c" fields of		signature MUST cover the resources in the primary key of the object
	the certificates, in case multiple signatures are present) MUST cover		(e.g., value of the "aut-num:" attribute of an aut-num object, value
	the resources in the primary key of the object (e.g., value of the		of the "inetnum:" attribute of an inetnum object, values of "route:"
	"aut-num:" attribute of an aut-num object, value of the "inetnum:"		and "origin:" attributes of a route object, etc.).
	attribute of an inetnum object, values of "route:" and "origin:"
	attributes of a route object, etc.).
	2.5. Validity Time of the Signature		2.5. Validity Time of the Signature
	The validity time interval of a signature is the intersection of the		The validity time interval of a signature is the intersection of the
	validity time of the certificate used to verify the signature, the		validity time of the certificate used to verify the signature, the
	"not before" time specified by the "t" field of the signature, and		"not before" time specified by the "t" field of the signature, and
	the optional "not after" time specified by the "x" field of the		the optional "not after" time specified by the "x" field of the
	signature.		signature.
	When checking multiple signatures, these checks are applied to each		When checking multiple signatures, these checks are applied to each
	skipping to change at page 12, line 48 ¶		skipping to change at page 13, line 8 ¶
	to use.		to use.
	7. IANA Considerations		7. IANA Considerations
	[Note to IANA, to be removed prior to publication: there are no IANA		[Note to IANA, to be removed prior to publication: there are no IANA
	considerations stated in this version of the document.]		considerations stated in this version of the document.]
	8. Acknowledgements		8. Acknowledgements
	The authors would like to acknowledge the valued contributions from		The authors would like to acknowledge the valued contributions from
	Jos Boumans, Steve Kent, Sean Turner, and Geoff Huston in preparation		Jos Boumans, Steve Kent, Sean Turner, Geoff Huston, and Stephen
	of this document.		Farrell in preparation of this document.
	9. Normative References		9. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,		[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
	Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,		Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
	skipping to change at page 13, line 27 ¶		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>.
			[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
			Algorithms and Identifiers for RSA Cryptography for use in
			the Internet X.509 Public Key Infrastructure Certificate
			and Certificate Revocation List (CRL) Profile", RFC 4055,
			DOI 10.17487/RFC4055, June 2005,
			<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,		[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
	skipping to change at page 14, line 10 ¶		skipping to change at page 14, line 20 ¶
	[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>.
	[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>.
	[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
	Use in the Resource Public Key Infrastructure (RPKI)",
	RFC 6485, DOI 10.17487/RFC6485, February 2012,
	<http://www.rfc-editor.org/info/rfc6485>.
	[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>.
	Authors' Addresses		Authors' Addresses
	Robert Kisteleki		Robert Kisteleki
	Email: robert@ripe.net		Email: robert@ripe.net
End of changes. 14 change blocks.
	30 lines changed or deleted		44 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/