< draft-ietf-sidr-rpsl-sig-07.txt		draft-ietf-sidr-rpsl-sig-08.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: November 12, 2015 JHU APL		Expires: April 11, 2016 JHU APL
	May 11, 2015		October 9, 2015
	Securing RPSL Objects with RPKI Signatures		Securing RPSL Objects with RPKI Signatures
	draft-ietf-sidr-rpsl-sig-07.txt		draft-ietf-sidr-rpsl-sig-08.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 November 12, 2015.		This Internet-Draft will expire on April 11, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 28 ¶		skipping to change at page 2, line 28 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . 12
	9. Normative References . . . . . . . . . . . . . . . . . . . . 12		9. Normative References . . . . . . . . . . . . . . . . . . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		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 an
	skipping to change at page 4, line 18 ¶		skipping to change at page 4, line 18 ¶
	RPKI repository [RFC6481]. The value of this field MUST be an		RPKI repository [RFC6481]. The value of this field MUST be an
	"rsync://..." or an "http[s]://..." URL. Any non URL-safe		"rsync://..." or an "http[s]://..." URL. Any non URL-safe
	characters (including semicolon ";" and plus "+") must be URL		characters (including semicolon ";" and plus "+") must be 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 [RFC6485].
	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 is the number of seconds since Unix EPOCH (00:00:00 on		field MUST be in the Internet Date/Time format [RFC3339]. All
	January 1, 1970 in the UTC time zone). The value is expressed as		times MUST be converted to Universal Coordinated Time (UTC)
	the decimal representation of an unsigned integer.
	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.
	o The signature itself (field "b"). This MUST be the last field in		o The signature itself (field "b"). This MUST be the last field in
	the list. The signature is the output of the signature algorithm		the list. The signature is the output of the signature algorithm
	using the appropriate private key and the calculated hash value of		using the appropriate private key and the calculated hash value of
	the object as inputs. The value of this field is the digital		the object as inputs. The value of this field is the digital
	signature in base64 encoding [RFC4648].		signature in base64 encoding [RFC4648].
	Optional fields of the "signature" attribute:		Optional fields of the "signature" attribute:
	o Signature expiration time (field "x"). The format of the value of		o Signature expiration time (field "x"). The format of the value of
	this field is the number of seconds since Unix EPOCH (00:00:00 on		this field MUST be in the Internet Date/Time format [RFC3339].
	January 1, 1970 in the UTC time zone). The value is expressed as		All times MUST be represented in UTC.
	the decimal representation of an unsigned integer.
	2.2. Signed Attributes		2.2. Signed Attributes
	One can look at an RPSL object as an (ordered) set of attributes,		One can look at an RPSL object as an (ordered) set of attributes,
	each having a "key: value" syntax. Understanding this structure can		each having a "key: value" syntax. Understanding this structure can
	help in developing more flexible methods for applying digital		help in developing more flexible methods for applying digital
	signatures.		signatures.
	Some of these attributes are automatically added by the database,		Some of these attributes are automatically added by the database,
	some are database-dependent, yet others do not carry operationally		some are database-dependent, yet others do not carry operationally
	important information. This specification allows the maintainer of		important information. This specification allows the maintainer of
	such an object to define which attributes are signed and which are		such an object to decide which attributes are important (signed) and
	not, from among all the attributes of the object; in other words, we		which are not (not signed), from among all the attributes of the
	define a way of including important attributes while excluding		object; in other words, we define a way of including important
	irrelevant ones. Allowing the maintainer an object to select the		attributes while excluding irrelevant ones. Allowing the maintainer
	attributes that are covered by the digital signature achieves the		of an object to select the attributes that are covered by the digital
	goals established in Section 1.		signature achieves the goals established in Section 1.
	The type of the object determines the minimum set of attributes that		The type of the object determines the minimum set of attributes that
	MUST be signed. The signer MAY choose to sign additional attributes,		MUST be signed. The signer MAY choose to sign additional attributes,
	in order to provide integrity protection for those attributes too.		in order to provide integrity protection for those attributes too.
	When verifying the signature of an object, the verifier has to check		When verifying the signature of an object, the verifier has to check
	whether the signature itself is valid, and whether all the specified		whether the signature itself is valid, and whether all the specified
	attributes are referenced in the signature. If not, the verifier		attributes are referenced in the signature. If not, the verifier
	MUST reject the signature and threat the object as a regular, non-		MUST reject the signature and threat the object as a regular, non-
	signed RPSL object.		signed RPSL object.
	skipping to change at page 5, line 36 ¶		skipping to change at page 5, line 33 ¶
	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=1; c=rsync://.....; m=sha256WithRSAEncryption;
	t=9999999999;		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.
	skipping to change at page 6, line 26 ¶		skipping to change at page 6, line 25 ¶
	When checking multiple signatures, these checks are applied to each		When checking multiple signatures, these checks are applied to each
	signature, individually.		signature, individually.
	3. Signature Creation and Validation Steps		3. Signature Creation and Validation Steps
	3.1. Canonicalization		3.1. Canonicalization
	The notion of canonicalization is essential to digital signature		The notion of canonicalization is essential to digital signature
	generation and validation whenever data representations may change		generation and validation whenever data representations may change
	between a signer and one or more signature verifiers.		between a signer and one or more signature verifiers.
	Canonicalization defines how one transforms an a representation of		Canonicalization defines how one transforms a representation of data
	data into a series of bits for signature generation and verification.		into a series of bits for signature generation and verification. The
	The task of canonicalization is to make irrelevant differences in		task of canonicalization is to make irrelevant differences in
	representations of the same object, which would otherwise cause		representations of the same object, which would otherwise cause
	signature verification to fail. Examples of this could be:		signature verification to fail. Examples of this could be:
	o data transformations applied by the databases that host these		o data transformations applied by the databases that host these
	objects (such as notational changes for IPv4/IPv6 prefixes,		objects (such as notational changes for IPv4/IPv6 prefixes,
	automatic addition/modification of "changed" attributes, etc.)		automatic addition/modification of "changed" attributes, etc.)
	o the difference of line terminators across different systems.		o the difference of line terminators across different systems.
	This means that the destination database might change parts of the		This means that the destination database might change parts of the
	skipping to change at page 7, line 17 ¶		skipping to change at page 7, line 15 ¶
	3. A multi-line attribute MUST be converted into its single-line		3. A multi-line attribute MUST be converted into its single-line
	equivalent. This is accomplished by:		equivalent. This is accomplished by:
	* Converting all line endings to a single blank space.		* Converting all line endings to a single blank space.
	* Concatenating all lines into a single line.		* Concatenating all lines into a single line.
	* Replacing the trailing blank space with a single new line		* Replacing the trailing blank space with a single new line
	("\n").		("\n").
	4. Numerical fields must be converted to canonical representations.		4. Numerical fields MUST be converted to canonical representations.
	These include:		These include:
	* Date and time fields MUST be converted to 64-bit NTP Timestamp		* Date and time fields MUST be converted to UTC and MUST be
	Format [RFC5905].		represented in the Internet Date/Time format [RFC3339].
	* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].		* AS numbers MUST be converted to ASPLAIN syntax [RFC5396].
	* IPv6 addresses must be canonicalized as defined in [RFC5952].		* IPv6 addresses MUST be canonicalized as defined in [RFC5952].
	* IPv4 addresses MUST be converted to a 32-bit representation		* IPv4 addresses MUST be represented as the ipv4-address type
	(e.g., Unix's inet_aton()).		defined by RPSL [RFC2622]
	* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR		* All IP prefixes (IPv4 and IPv6) MUST be represented in CIDR
	notaion [RFC4632].		notation [RFC4632].
	5. The name of each attribute MUST be converted into lower case, and		5. All ranges, lists, or sets of numerical fields are represented
			using the appropriate RPSL attribute and each numerical element
			contained within those attributes MUST conform to the
			canonicalization rules in this document.
			6. The name of each attribute MUST be converted into lower case, and
	MUST be kept as part of the attribute line.		MUST be kept as part of the attribute line.
	6. Tab characters ("\t") MUST be converted to spaces.		7. Tab characters ("\t") MUST be converted to spaces.
	7. Multiple whitespaces MUST be collapsed into a single space (" ")		8. Multiple whitespaces MUST be collapsed into a single space (" ")
	character.		character.
	8. All line endings MUST be converted to a singe new line ("\n")		9. All line endings MUST be converted to a singe new line ("\n")
	character (thus avoiding CR vs. CRLF differences).		character (thus avoiding CR vs. CRLF differences).
	3.2. Signature Creation		3.2. Signature Creation
	Given an RPSL object, in order to create the digital signature, the		Given an RPSL object, in order to create the digital signature, the
	following steps MUST be performed:		following steps MUST be performed:
	1. For each signature, a new key pair and certificate SHOULD be		1. For each signature, a new public/private key pair and certificate
	used. Therefore the signer SHOULD create a single-use key pair		SHOULD be used. Therefore the signer SHOULD create a single-use
	and end-entity resource certificate (see [RFC6487]) to be used		key pair and end-entity resource certificate (see [RFC6487]).
	for signing this object this time.		The private key is used for signing this object this time.
	2. Create a list of attribute names referring to the attributes that		2. Create a list of attribute names referring to the attributes that
	will be signed (contents of the "a" field). The minimum set of		will be signed (contents of the "a" field). The minimum set of
	these attributes is determined by the object type; the signer MAY		these attributes is determined by the object type; the signer MAY
	select additional attributes.		select additional attributes.
	3. Arrange the selected attributes according to the selection		3. Arrange the selected attributes according to the selection
	sequence specified in the "a" field as above, omiting all		sequence specified in the "a" field as above, omitting all
	attributes that will not be signed.		attributes that will not be signed.
	4. Construct the new "signature" attribute, with all its fields,		4. Construct the new "signature" attribute, with all its fields,
	leaving the value of the "b" field empty.		leaving the value of the "b" field empty.
	5. Apply canonicalization rules to the result (including the		5. Apply canonicalization rules to the result (including the
	"signature" attribute).		"signature" attribute).
	6. Create the signature over the results of the canonicalization		6. Create the signature over the results of the canonicalization
	process (according to the signature and hash algorithms specified		process (according to the signature and hash algorithms specified
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 13 ¶
	the "b" field.		the "b" field.
	8. Append the resulting "signature" attribute to the original		8. Append the resulting "signature" attribute to the original
	object.		object.
	3.3. Signature Validation		3.3. Signature Validation
	In order to validate a signature over such an object, the following		In order to validate a signature over such an object, the following
	steps MUST be performed:		steps MUST be performed:
	1. Verify the syntax of the "signature" attribute (ie. whether it		1. Verify the syntax of the "signature" attribute (i.e., whether it
	contains the mandatory and optional components and the syntax of		contains the mandatory and optional components and the syntax of
	these fields mathces the specification as described in section		these fields matches the specification as described in section
	2.1.)		2.1.)
	2. Fetch the certificate referred to in the "c" field of the		2. Fetch the certificate referred to in the "c" field of the
	"signature" attribute, and check its validity using the steps		"signature" attribute, and check its validity using the steps
	described in [RFC6487].		described in [RFC6487].
	3. Extract the list of attributes that were signed using the signer		3. Extract the list of attributes that were signed using the signer
	from the "a" field of the "signature" attribute.		from the "a" field of the "signature" attribute.
	4. Verify that the list of signed attributes matches the miminum set		4. Verify that the list of signed attributes includes the minimum
	of attributes for that object type.		set of attributes for that object type.
	5. Arrange the selected attributes according to the selection		5. Arrange the selected attributes according to the selection
	sequence provided in the value of the "a" field, omitting all		sequence provided in the value of the "a" field, omitting all
	non-signed attributes.		non-signed attributes.
	6. Replace the value of the signature field "b" of the "signature"		6. Replace the value of the signature field "b" of the "signature"
	attribute with an empty string.		attribute with an empty string.
	7. Apply the canonicalization procedure to the selected attributes		7. Apply the canonicalization procedure to the selected attributes
	(including the "signature" attribute).		(including the "signature" attribute).
	skipping to change at page 10, line 8 ¶		skipping to change at page 10, line 8 ¶
	8. Check the validity of the signature using the signature algorithm		8. Check the validity of the signature using the signature algorithm
	specified in the "m" field of the signature attribute, the public		specified in the "m" field of the signature attribute, the public
	key contained in the certificate mentioned in the "c" field of		key contained in the certificate mentioned in the "c" field of
	the signature, the signature value specified in the "b" field of		the signature, the signature value specified in the "b" field of
	the signature attribute, and the output of the canonicalization		the signature attribute, and the output of the canonicalization
	process.		process.
	4. Signed Object Types, Set of Signed Attributes		4. Signed Object Types, Set of Signed Attributes
	This section describes a list of object types that MAY signed using		This section describes a list of object types that MAY signed using
	this approach, and the set of attributes that MUST be signed for		this approach. For each object type, the set of attributes that MUST
	these object types.		be signed for these object types (the minimum set noted in
			Section Section 3.3 is enumerated.
	This list generally excludes attributes that are used to maintain		This list generally excludes attributes that are used to maintain
	referential integrity in the databases that carry these objects,		referential integrity in the databases that carry these objects,
	since these usually make sense only within the context of such a		since these usually make sense only within the context of such a
	database, whereas the scope of the signatures is only one specific		database, whereas the scope of the signatures is only one specific
	object. Since the attributes in the referred object (such as mnt-by,		object. Since the attributes in the referred object (such as mnt-by,
	admin-c, tech-c, ...) can change without any modifications to the		admin-c, tech-c, ...) can change without any modifications to the
	signed object, signing such attributes could lead to false sense of		signed object, signing such attributes could lead to false sense of
	security in terms of the contents of the signed data; therefore		security in terms of the contents of the signed data; therefore
	should only be done in order to provide full integrity protection of		including such attributes should only be done in order to provide
	the object itself.		full integrity protection of the object itself.
	The newly constructed "signature" attribute is always included in the		The newly constructed "signature" attribute is always included in the
	list.		list.
	as-block:		as-block:
	* as-block		* as-block
	* org		* org
	skipping to change at page 11, line 35 ¶		skipping to change at page 11, line 35 ¶
	* holes		* holes
	* org		* org
	* member-of		* member-of
	* signature		* signature
	For each signature, the RFC3779 extension appearing in the		For each signature, the RFC3779 extension appearing in the
	certificate used to verify the signature SHOULD include a resource		certificate used to verify the signature MUST include a resource
	entry that is equivalent to, or covers ("less specific" than) the		entry that is equivalent to, or covers ("less specific" than) the
	following resources mentioned in the object the signatrure is		following resources mentioned in the object the signature is attached
	attached to:		to:
	o For the as-block object type: the resource in the "as-block"		o For the as-block object type: the resource in the "as-block"
	attribute.		attribute.
	o For the aut-num object type: the resource in the "aut-num"		o For the aut-num object type: the resource in the "aut-num"
	attribute.		attribute.
	o For the inet[6]num object type: the resource in the "inet[6]num"		o For the inet[6]num object type: the resource in the "inet[6]num"
	attribute.		attribute.
	skipping to change at page 12, line 18 ¶		skipping to change at page 12, line 18 ¶
	5. Keys and Certificates used for Signature and Verification		5. Keys and Certificates used for Signature and Verification
	The certificate that is referred to in the signature (in the "c"		The certificate that is referred to in the signature (in the "c"
	field):		field):
	o MUST be an end-entity (ie. non-CA) certificate		o MUST be an end-entity (ie. non-CA) certificate
	o MUST conform to the X.509 PKIX Resource Certificate profile		o MUST conform to the X.509 PKIX Resource Certificate profile
	[RFC6487]		[RFC6487]
	o MUST have an [RFC3779] extension that contains or covers at least		o MUST have an [RFC3779] extension that covers the Internet number
	one Internet number resource included in a signed attribute.		resource included in a signed attribute.
	o SHOULD NOT be used to verify more than one signed object (ie.		o SHOULD NOT be used to verify more than one signed object (ie.
	should be a "single-use" EE certificate, as defined in [RFC6487]).		should be a "single-use" EE certificate, as defined in [RFC6487]).
	6. Security Considerations		6. Security Considerations
	RPSL objects stored in the IRR databases are public, and as such		RPSL objects stored in the IRR databases are public, and as such
	there is no need for confidentiality. Each signed RPSL object can		there is no need for confidentiality. Each signed RPSL object can
	have its integrity and authenticity verified using the supplied		have its integrity and authenticity verified using the supplied
	digital signature and the referenced certificate.		digital signature and the referenced certificate.
	Since the RPSL signature approach leverages X.509 extensions, the		Since the RPSL signature approach leverages X.509 extensions, the
	security considerations in [RFC3779] apply here as well.		security considerations in [RFC3779] apply here as well.
			The maintainer of an object has the ability to include attributes in
			the signature that are not included in the resource certificate used
			to create the signature. Potentially, a maintainer may include
			attributes that reference resources the maintainer is not authorized
			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, and Sean Turner in preparation of this		Jos Boumans, Steve Kent, Sean Turner, and Geoff Huston in preparation
	document.		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, March 1997.		Requirement Levels", BCP 14, RFC 2119,
			DOI 10.17487/RFC2119, March 1997,
			<http://www.rfc-editor.org/info/rfc2119>.
			[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
			Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra,
			"Routing Policy Specification Language (RPSL)", RFC 2622,
			DOI 10.17487/RFC2622, June 1999,
			<http://www.rfc-editor.org/info/rfc2622>.
			[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
			Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
			<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, June 2004.		Addresses and AS Identifiers", RFC 3779,
			DOI 10.17487/RFC3779, June 2004,
			<http://www.rfc-editor.org/info/rfc3779>.
	[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, August 2006.		Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
			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, October 2006.		Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
			<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,
	J., and M. Thomas, "DomainKeys Identified Mail (DKIM)		J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
	Signatures", RFC 4871, May 2007.		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, December 2008.		Autonomous System (AS) Numbers", RFC 5396,
			DOI 10.17487/RFC5396, December 2008,
	[RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network		<http://www.rfc-editor.org/info/rfc5396>.
	Time Protocol Version 4: Protocol and Algorithms
	Specification", RFC 5905, June 2010.
	[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, August 2010.		Address Text Representation", RFC 5952,
			DOI 10.17487/RFC5952, August 2010,
			<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,
	February 2012.		DOI 10.17487/RFC6481, February 2012,
			<http://www.rfc-editor.org/info/rfc6481>.
	[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for		[RFC6485] Huston, G., "The Profile for Algorithms and Key Sizes for
	Use in the Resource Public Key Infrastructure (RPKI)", RFC		Use in the Resource Public Key Infrastructure (RPKI)",
	6485, February 2012.		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, February		X.509 PKIX Resource Certificates", RFC 6487,
	2012.		DOI 10.17487/RFC6487, February 2012,
			<http://www.rfc-editor.org/info/rfc6487>.
	Authors' Addresses		Authors' Addresses
	Robert Kisteleki		Robert Kisteleki
	Email: robert@ripe.net		Email: robert@ripe.net
	URI: http://www.ripe.net		URI: http://www.ripe.net
	Brian Haberman		Brian Haberman
	Johns Hopkins University Applied Physics Lab		Johns Hopkins University Applied Physics Lab
End of changes. 40 change blocks.
	69 lines changed or deleted		99 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/