draft-ietf-mile-rolie-08.txt		draft-ietf-mile-rolie-09.txt
	MILE Working Group J. Field		MILE Working Group J. Field
	Internet-Draft Pivotal		Internet-Draft Pivotal
	Intended status: Standards Track S. Banghart		Intended status: Standards Track S. Banghart
	Expires: January 18, 2018 D. Waltermire		Expires: March 30, 2018 D. Waltermire
	NIST		NIST
	July 17, 2017		September 26, 2017
	Resource-Oriented Lightweight Information Exchange		Resource-Oriented Lightweight Information Exchange
	draft-ietf-mile-rolie-08		draft-ietf-mile-rolie-09
	Abstract		Abstract
	This document defines a resource-oriented approach for security		This document defines a resource-oriented approach for security
	automation information publication, discovery, and sharing. Using		automation information publication, discovery, and sharing. Using
	this approach, producers may publish, share, and exchange		this approach, producers may publish, share, and exchange
	representations of software descriptors, security incidents, attack		representations of software descriptors, security incidents, attack
	indicators, software vulnerabilities, configuration checklists, and		indicators, software vulnerabilities, configuration checklists, and
	other security automation information as web-addressable resources.		other security automation information as web-addressable resources.
	Furthermore, consumers and other stakeholders may access and search		Furthermore, consumers and other stakeholders may access and search
	skipping to change at page 1, line 44 ¶		skipping to change at page 1, line 44 ¶
	substantial issues need to be discussed on the MILE mailing list.		substantial issues need to be discussed on the MILE mailing list.
	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 https://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 January 18, 2018.		This Internet-Draft will expire on March 30, 2018.
	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		(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	skipping to change at page 3, line 18 ¶		skipping to change at page 3, line 18 ¶
	7.3. The Link Relation Extension Point . . . . . . . . . . . . 23		7.3. The Link Relation Extension Point . . . . . . . . . . . . 23
	7.4. The "rolie:property" Extension Point . . . . . . . . . . 23		7.4. The "rolie:property" Extension Point . . . . . . . . . . 23
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
	8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24		8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24
	8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25		8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25
	8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25		8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25
	8.4. ROLIE Security Resource Information Type Sub-Registry . . 28		8.4. ROLIE Security Resource Information Type Sub-Registry . . 28
	8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28		8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 29		9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.1. Normative References . . . . . . . . . . . . . . . . . . 32
	12.2. Informative References . . . . . . . . . . . . . . . . . 33		12.2. Informative References . . . . . . . . . . . . . . . . . 34
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
	Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35		Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36
	Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36		Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37
	B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36		B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37
	B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39		B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40
	B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41		B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42
	Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42		Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
	1. Introduction		1. Introduction
	This document defines a resource-oriented approach to security		This document defines a resource-oriented approach to security
	automation information sharing that follows the Representational		automation information sharing that follows the Representational
	State Transfer (REST) architectural style [REST]. In this approach,		State Transfer (REST) architectural style [REST]. In this approach,
	computer security resources are maintained in web-accessible		computer security resources are maintained in web-accessible
	repositories structured as Atom Syndication Format [RFC4287] Feeds.		repositories structured as Atom Syndication Format [RFC4287] Feeds.
	Within a given Feed, which may be requested by the consumer,		Within a given Feed, which may be requested by the consumer,
	representations of specific types of security automation information		representations of specific types of security automation information
	skipping to change at page 4, line 9 ¶		skipping to change at page 4, line 9 ¶
	The goal of this approach is to increase the communication and		The goal of this approach is to increase the communication and
	sharing of security information between providers and consumers that		sharing of security information between providers and consumers that
	can be used to automate security processes (e.g., incident reports,		can be used to automate security processes (e.g., incident reports,
	vulnerability assessments, configuration checklists, and other		vulnerability assessments, configuration checklists, and other
	security automation information). Such sharing allows human		security automation information). Such sharing allows human
	operators and computer systems to leverage this standardized		operators and computer systems to leverage this standardized
	communication system to gather information that supports the		communication system to gather information that supports the
	automation of security processes.		automation of security processes.
	In for new types of security automation information and associated		To support new types of security automation information being used as
	resource representations to be shared over time, this specification		time goes on, this specification defines a number of extension points
	defines extension points that can be used to add support for new		that can be used either privately or globally. These global
	information types and associated resource representations by means of		extensions are IANA registered by ROLIE extension specifications, and
	additional supplementary specification documents. Sections 5 and 6		provide enhanced interoperability for new use cases and domains.
	of this document define the core requirements of all implementations		Sections 5 and 6 of this document define the core requirements of all
	of this specification, and is resource representation agnostic. An		implementations of this specification, and is resource representation
	overview of the extension system is provided in Section 7.		agnostic. An overview of the extension system is provided in
	Implementers seeking to provide support for specific security		Section 7. Implementers seeking to provide support for specific
	automation information types should refer to the specification for		security automation information types should refer to the
	that domain described by the IANA registry found in section 8.4.		specification for that domain described by the IANA registry found in
			section 8.4.
	2. Terminology		2. Terminology
	The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"		The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT,"
	"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this		"SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The previous key words are used in this document to define the		The previous key words are used in this document to define the
	conformance requirements for implementations of this specification.		conformance requirements for implementations of this specification.
	This document does not give any recommendations for the use of ROLIE,		This document does not give any recommendations for the use of ROLIE,
	skipping to change at page 10, line 20 ¶		skipping to change at page 10, line 20 ¶
	This allows clients to have a well-known location to find a ROLIE		This allows clients to have a well-known location to find a ROLIE
	category document, while giving implementations flexibility over how		category document, while giving implementations flexibility over how
	the service is deployed.		the service is deployed.
	This document registers the "rolie/categorydocument" well-known URI		This document registers the "rolie/categorydocument" well-known URI
	as per [RFC5785] in Section 8.5.		as per [RFC5785] in Section 8.5.
	5.3. Transport Layer Security		5.3. Transport Layer Security
	ROLIE is intended to be handled with TLS. The following requirements		ROLIE is intended to be handled with TLS. The following requirements
	have been derived from [RFC7589].		have been in part derived from [RFC7589].
	The most recent published version of TLS MUST be supported, and any		TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
	mandatory-to-implement (MTI) cipher suites in that version MUST be		according to all recommendations and best practices present in
	supported as well.		[RFC7525].
			It is RECOMMENDED that the most recent published version of TLS is
			supported. If this version is TLS 1.3, it is recommended that 0-RTT
			(Zero Round Trip Time Resumption) is not used, as there is a replay
			attack that is possible with that option.
	The server MUST support certificate-based client authentication. An		The server MUST support certificate-based client authentication. An
	implementation MUST support the set of TLS cipher suites that are		implementation MUST support the set of TLS cipher suites that are
	REQUIRED by the latest published version of the TLS specification.		REQUIRED by the latest published version of the TLS specification.
	An implementation MUST also support the TLS cipher suites that		An implementation MUST also support the TLS cipher suites that
	provide support for mutual authentication of clients and servers.		provide support for mutual authentication of clients and servers.
	During the TLS negotiation, the client MUST carefully examine the		During the TLS negotiation, the client MUST carefully examine the
	certificate presented by the server to determine if it meets the		certificate presented by the server to determine if it meets the
	client's expectations. Particularly, the client MUST check its		client's expectations. Particularly, the client MUST check its
	skipping to change at page 11, line 15 ¶		skipping to change at page 11, line 21 ¶
	configuration or state data is sent to or received from the client.		configuration or state data is sent to or received from the client.
	5.4. User Authentication and Authorization		5.4. User Authentication and Authorization
	Implementations MUST support user authentication. However, a given		Implementations MUST support user authentication. However, a given
	implementation MAY allow user authentication to be disabled on a feed		implementation MAY allow user authentication to be disabled on a feed
	by feed basis.		by feed basis.
	Servers participating in an information sharing consortium and		Servers participating in an information sharing consortium and
	supporting interactive user logins by members of the consortium		supporting interactive user logins by members of the consortium
	SHOULD support client authentication via a federated identity scheme		SHOULD support client authentication via a federated identity scheme.
	(e.g., SAML 2.0).
	This document does not mandate the use of any specific user		This document does not mandate the use of any specific user
	authorization mechanisms. However, service implementers SHOULD		authorization mechanisms. However, service implementers SHOULD
	provide appropriate authorization checking for all resource accesses,		provide appropriate authorization checking for all resource accesses,
	including individual Atom Entries, Atom Feeds, and Atom Service		including individual Atom Entries, Atom Feeds, and Atom Service
	Documents.		Documents.
	5.5. / (forward slash) Resource URL		5.5. / (forward slash) Resource URL
	The "/" resource MAY be supported for compatibility with existing		The "/" resource MAY be supported for compatibility with existing
	skipping to change at page 20, line 47 ¶		skipping to change at page 20, line 47 ¶
	mechanism by allowing ROLIE specific category extensions to be		mechanism by allowing ROLIE specific category extensions to be
	registered with IANA, and additionally has assigned the		registered with IANA, and additionally has assigned the
	"urn:ietf:params:rolie:category:information-type" category scheme		"urn:ietf:params:rolie:category:information-type" category scheme
	that has special meaning for implementations of ROLIE. This allows		that has special meaning for implementations of ROLIE. This allows
	category scheme namespaces to be managed in a more consistent way,		category scheme namespaces to be managed in a more consistent way,
	allowing for greater interoperability between content producers and		allowing for greater interoperability between content producers and
	consumers.		consumers.
	The namespace "urn:ietf:params:rolie:category:local" has been		The namespace "urn:ietf:params:rolie:category:local" has been
	reserved in the IANA ROLIE Parameters table for private use as		reserved in the IANA ROLIE Parameters table for private use as
	defined in [RFC5226]. Any category whose "scheme" attribute uses		defined in [RFC8126]. Any category whose "scheme" attribute uses
	this as a prefix MUST be considered private use. Implementations		this as a prefix MUST be considered private use. Implementations
	encountering such a category MUST parse the content without error,		encountering such a category MUST parse the content without error,
	but MAY otherwise ignore the element.		but MAY otherwise ignore the element.
	Use of the "atom:category" element is discussed in the following		Use of the "atom:category" element is discussed in the following
	subsections.		subsections.
	7.1.1. General Use of the "atom:category" Element		7.1.1. General Use of the "atom:category" Element
	The atom:category element can be used for characterizing a ROLIE		The atom:category element can be used for characterizing a ROLIE
	skipping to change at page 21, line 31 ¶		skipping to change at page 21, line 31 ¶
	support the registration of new category "scheme" attribute values by		support the registration of new category "scheme" attribute values by
	ROLIE extension specifications. Use of this extension point is		ROLIE extension specifications. Use of this extension point is
	discussed in section 8.3 using the name field with a type parameter		discussed in section 8.3 using the name field with a type parameter
	of "category" to indicate a category extension.		of "category" to indicate a category extension.
	7.1.2. Identification of Security Automation Information Types		7.1.2. Identification of Security Automation Information Types
	A ROLIE specific extension point is provided through the		A ROLIE specific extension point is provided through the
	atom:category "scheme" value		atom:category "scheme" value
	"urn:ietf:params:rolie:category:information-type". This value is a		"urn:ietf:params:rolie:category:information-type". This value is a
	Uniform Resource Name (URN) [RFC2141] that is registered with IANA as		Uniform Resource Name (URN) [RFC8141] that is registered with IANA as
	described in section 8.3. When used as the "scheme" attribute in		described in section 8.3. When used as the "scheme" attribute in
	this way, the "term" attribute is expected to be a registered value		this way, the "term" attribute is expected to be a registered value
	as defined in section Section 8.4. Through this mechanism a given		as defined in section Section 8.4. Through this mechanism a given
	security automation information type can be used to:		security automation information type can be used to:
	1. identify that an "app:collection" element in a Service Document		1. identify that an "app:collection" element in a Service Document
	points to an Atom Feed that contains Entries pertaining to a		points to an Atom Feed that contains Entries pertaining to a
	specific type of security automation information (see section		specific type of security automation information (see section
	5.1.2), or		5.1.2), or
	skipping to change at page 22, line 32 ¶		skipping to change at page 22, line 32 ¶
	configuration checklists: Content that can be used to assess the		configuration checklists: Content that can be used to assess the
	configuration settings related to installed software.		configuration settings related to installed software.
	software tags: Metadata used to identify and characterize		software tags: Metadata used to identify and characterize
	installable software.		installable software.
	This is a short list to inspire new engineering of information type		This is a short list to inspire new engineering of information type
	extensions that support the automation of security processes.		extensions that support the automation of security processes.
	This document does not specific any information types. Instead,		This document does not specify any information types. Instead,
	information types in ROLIE are expected to be registered in extension		information types in ROLIE are expected to be registered in extension
	documents that describe one or more new information types. This		documents that describe one or more new information types. This
	allows the information types used by ROLIE implementations to grow		allows the information types used by ROLIE implementations to grow
	over time to support new security automation use cases. These		over time to support new security automation use cases. These
	extension documents may also enhance ROLIE Service, Category, Feed,		extension documents may also enhance ROLIE Service, Category, Feed,
	and Entry documents by defining link relations, other categories, and		and Entry documents by defining link relations, other categories, and
	Format data model extensions to address the representational needs of		Format data model extensions to address the representational needs of
	these specific information types. New information types are added to		these specific information types. New information types are added to
	ROLIE through registrations to the IANA ROLIE Security Resource		ROLIE through registrations to the IANA ROLIE Security Resource
	Information Type registry defined in section 8.4.		Information Type registry defined in section 8.4.
	skipping to change at page 23, line 40 ¶		skipping to change at page 23, line 40 ¶
	name field with a type parameter of "property" to indicate a property		name field with a type parameter of "property" to indicate a property
	extension. Implementations SHOULD prefer the use of registered		extension. Implementations SHOULD prefer the use of registered
	properties over implementation specific properties when possible.		properties over implementation specific properties when possible.
	ROLIE extensions are expected to register new and use existing		ROLIE extensions are expected to register new and use existing
	properties to provide valuable identifying and characterizing		properties to provide valuable identifying and characterizing
	information for a given information type and/or format.		information for a given information type and/or format.
	The namespace "urn:ietf:params:rolie:property:local" has been		The namespace "urn:ietf:params:rolie:property:local" has been
	reserved in the IANA ROLIE Parameters table for private use as		reserved in the IANA ROLIE Parameters table for private use as
	defined in [RFC5226]. Any property whose "name" attribute uses this		defined in [RFC8126]. Any property whose "name" attribute uses this
	as a prefix MUST be considered private use. Implementations		as a prefix MUST be considered private use. Implementations
	encountering such a property MUST parse the content without error,		encountering such a property MUST parse the content without error,
	but MAY otherwise ignore the element.		but MAY otherwise ignore the element.
	This document also registers a number of general use properties that		This document also registers a number of general use properties that
	can be used to expose content information in any ROLIE use case. The		can be used to expose content information in any ROLIE use case. The
	following are descriptions of how to use these registered properties:		following are descriptions of how to use these registered properties:
	urn:ietf:params:rolie:property:content-author-name The "value"		urn:ietf:params:rolie:property:content-author-name The "value"
	attribute of this property is a text representation indicating the		attribute of this property is a text representation indicating the
	skipping to change at page 25, line 36 ¶		skipping to change at page 25, line 36 ¶
	8.3. ROLIE URN Parameters		8.3. ROLIE URN Parameters
	A new top-level registry has been created, entitled "Resource		A new top-level registry has been created, entitled "Resource
	Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO		Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO
	BE REMOVED: This registration should take place at the following		BE REMOVED: This registration should take place at the following
	location: https://www.iana.org/assignments/rolie]		location: https://www.iana.org/assignments/rolie]
	In this top-level registry, a sub-registry entitled "ROLIE URN		In this top-level registry, a sub-registry entitled "ROLIE URN
	Parameters" has been created. Registration in this repository is via		Parameters" has been created. Registration in this repository is via
	the Specification Required policy [RFC5226]. Designated Expert		the Specification Required policy [RFC8126]. Designated Expert
	reviews should be routed through the MILE WG mailing list. Failing		reviews should be routed through the MILE WG mailing list. Failing
	this, the Designated Expert will be assigned by the IESG.		this, the Designated Expert will be assigned by the IESG. The
			authors recommend the following individuals be assigned by the IESG
			as Designated Experts:
			Stephen Banghart <stephen.banghart@nist.gov>
			David Waltermire <david.waltermire@nist.gov>
	Each entry in this sub-registry must record the following fields:		Each entry in this sub-registry must record the following fields:
	Name: A URN segment that adheres to the pattern {type}:{label}.		Name: A URN segment that adheres to the pattern {type}:{label}.
	The keywords are defined as follows:		The keywords are defined as follows:
	{type}: The parameter type. The allowed values are "category"		{type}: The parameter type. The allowed values are "category"
	or "property". "category" denotes a category extension as		or "property". "category" denotes a category extension as
	discussed in Section 7.1. "property" denotes a property		discussed in Section 7.1. "property" denotes a property
	extension as discussed in Section 7.4.		extension as discussed in Section 7.4.
	{label}: A required US-ASCII string that conforms to the URN		{label}: A required US-ASCII string that conforms to the URN
	syntax requirements (see [RFC2141]). This string must be		syntax requirements (see [RFC8141]). This string must be
	unique within the namespace defined by the {type} keyword. The		unique within the namespace defined by the {type} keyword. The
	"local" label for both the "category" and "property" types has		"local" label for both the "category" and "property" types has
	been reserved for private use.		been reserved for private use.
	Extension IRI: The identifier to use within ROLIE, which is the		Extension IRI: The identifier to use within ROLIE, which is the
	full URN using the form: urn:ietf:params:rolie:{name}, where		full URN using the form: urn:ietf:params:rolie:{name}, where
	{name} is the "name" field of this registration.		{name} is the "name" field of this registration.
	Reference: A static link to the specification and section that the		Reference: A static link to the specification and section that the
	definition of the parameter can be found.		definition of the parameter can be found.
	skipping to change at page 28, line 34 ¶		skipping to change at page 28, line 34 ¶
	index: This is an IANA-assigned positive integer that		index: This is an IANA-assigned positive integer that
	identifies the registration. The first entry added to this		identifies the registration. The first entry added to this
	registry uses the value 1, and this value is incremented for		registry uses the value 1, and this value is incremented for
	each subsequent entry added to the registry.		each subsequent entry added to the registry.
	reference: A list of one or more URIs [RFC3986] from which the		reference: A list of one or more URIs [RFC3986] from which the
	registered specification can be obtained. The registered		registered specification can be obtained. The registered
	specification MUST be readily and publicly available from that		specification MUST be readily and publicly available from that
	URI. The URI SHOULD be a stable reference.		URI. The URI SHOULD be a stable reference.
	Allocation Policy: Specification required as per [RFC5226]		Allocation Policy: Specification required as per [RFC8126]
	8.5. Well-Known URI Registrations		8.5. Well-Known URI Registrations
	This document makes the follow two registrations to the Well-Known		This document makes the follow two registrations to the Well-Known
	URI Registry at https://www.iana.org/assignments/well-known-uris/		URI Registry at https://www.iana.org/assignments/well-known-uris/
	well-known-uris.xhtml.		well-known-uris.xhtml.
	Service Document registration:		Service Document registration:
	URI suffix: rolie/servicedocument		URI suffix: rolie/servicedocument
	skipping to change at page 29, line 36 ¶		skipping to change at page 29, line 36 ¶
	access to sensitive resources to verify that proper access controls		access to sensitive resources to verify that proper access controls
	remain in place over time.		remain in place over time.
	The approach described herein is based upon all policy enforcements		The approach described herein is based upon all policy enforcements
	being implemented at the point when a resource representation is		being implemented at the point when a resource representation is
	created. As such, producers sharing cyber security information using		created. As such, producers sharing cyber security information using
	this specification must take care to authenticate their HTTP clients		this specification must take care to authenticate their HTTP clients
	using a suitably strong user authentication mechanism. Sharing		using a suitably strong user authentication mechanism. Sharing
	communities that are exchanging information on well-known indicators		communities that are exchanging information on well-known indicators
	and incidents for purposes of public education may choose to rely		and incidents for purposes of public education may choose to rely
	upon HTTP Authentication or similar. However, sharing communities		upon HTTP Authentication or similar. A number of authentication
	that are engaged in sensitive collaborative analysis and/or		schemes are defined in the HTTP Authentication Schemes Registry [3].
	operational response for indicators and incidents targeting high		Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved
	value information systems should adopt a suitably stronger user		security properties over HTTP Basic [RFC7617]and Digest [RFC7616]
			Authentication Schemes. However, sharing communities that are
			engaged in sensitive collaborative analysis and/or operational
			response for indicators and incidents targeting high value
			information systems should adopt a suitably stronger user
	authentication solution, such as a risk-based or multi-factor		authentication solution, such as a risk-based or multi-factor
	approach. In general, trust in the sharing consortium will depend		approach. In general, trust in the sharing consortium will depend
	upon the members maintaining adequate user authentication mechanisms.		upon the members maintaining adequate user authentication mechanisms.
	Collaborating consortiums may benefit from the adoption of a		Collaborating consortiums may benefit from the adoption of a
	federated identity solution, such as those based upon SAML-core		federated identity solution, such as those based upon [RFC6749], or
	[SAML-core], SAML-bind [SAML-bind], and SAML-prof [SAML-prof] for		SAML-core [SAML-core], SAML-bind [SAML-bind], and SAML-prof
	Web-based authentication and cross-organizational single sign-on.		[SAML-prof] for Web-based authentication and cross-organizational
	Dependency on a trusted third party identity provider implies that		single sign-on. Dependency on a trusted third party identity
	appropriate care must be exercised to sufficiently secure the		provider implies that appropriate care must be exercised to
	Identity provider. Any attacks on the federated identity system		sufficiently secure the Identity provider. Any attacks on the
	would present a risk to the consortium, as a relying party.		federated identity system would present a risk to the consortium, as
	Potential mitigations include deployment of a federation-aware		a relying party. Potential mitigations include deployment of a
	identity provider that is under the control of the information		federation-aware identity provider that is under the control of the
	sharing consortium, with suitably stringent technical and management		information sharing consortium, with suitably stringent technical and
	controls.		management controls.
	Authorization of resource representations is the responsibility of		Authorization of resource representations is the responsibility of
	the source system, i.e. based on the authenticated user identity		the source system, i.e. based on the authenticated user identity
	associated with an HTTP(S) request. The required authorization		associated with an HTTP(S) request. The required authorization
	policies that are to be enforced must therefore be managed by the		policies that are to be enforced must therefore be managed by the
	security administrators of the source system. Various authorization		security administrators of the source system. Various authorization
	architectures would be suitable for this purpose, such as RBAC [3]		architectures would be suitable for this purpose, such as RBAC [4]
	and/or ABAC, as embodied in XACML [XACML]. In particular,		and/or ABAC, as embodied in XACML [XACML]. In particular,
	implementers adopting XACML may benefit from the capability to		implementers adopting XACML may benefit from the capability to
	represent their authorization policies in a standardized,		represent their authorization policies in a standardized,
	interoperable format. Note that implementers are free to choose any		interoperable format. Note that implementers are free to choose any
	suitable authorization mechanism that is capable of fulfilling the		suitable authorization mechanism that is capable of fulfilling the
	policy enforcement requirements relevant to their consortium and/or		policy enforcement requirements relevant to their consortium and/or
	organization.		organization.
	Additional security requirements such as enforcing message-level		Additional security requirements such as enforcing message-level
	security at the destination system could supplement the security		security at the destination system could supplement the security
	enforcements performed at the source system, however these		enforcements performed at the source system, however these
	destination-provided policy enforcements are out of scope for this		destination-provided policy enforcements are out of scope for this
	specification. Implementers requiring this capability should		specification. Implementers requiring this capability should
	consider leveraging, e.g. the <RIDPolicy> element in the RID schema.		consider leveraging, e.g. the <RIDPolicy> element in the RID schema.
	Refer to RFC6545 section 9 for more information.		Refer to RFC6545 section 9 for more information. Additionally, the
			underlying serialization approach used in the message (e.g., XML,
			JSON) can offer encryption and message authentication capabilities.
			For example, XMLDSig [RFC3275] for XML, and JSON Web Encryption
			[RFC7516] and JSON Web Signature[RFC7515] for JSON can provide such
			mechanisms.
	When security policies relevant to the source system are to be		When security policies relevant to the source system are to be
	enforced at both the source and destination systems, implementers		enforced at both the source and destination systems, implementers
	must take care to avoid unintended interactions of the separately		must take care to avoid unintended interactions of the separately
	enforced policies. Potential risks will include unintended denial of		enforced policies. Potential risks will include unintended denial of
	service and/or unintended information leakage. These problems may be		service and/or unintended information leakage. These problems may be
	mitigated by avoiding any dependence upon enforcements performed at		mitigated by avoiding any dependence upon enforcements performed at
	the destination system. When distributed enforcement is unavoidable,		the destination system. When distributed enforcement is unavoidable,
	the usage of a standard language (e.g. XACML) for the expression of		the usage of a standard language (e.g. XACML) for the expression of
	authorization policies will enable the source and destination systems		authorization policies will enable the source and destination systems
	skipping to change at page 31, line 41 ¶		skipping to change at page 31, line 45 ¶
	specification, and a similar potential for abuse exists with any		specification, and a similar potential for abuse exists with any
	other cyber security information sharing protocol. However, the wide		other cyber security information sharing protocol. However, the wide
	availability of tools for HTTP clients and Atom Feed handling implies		availability of tools for HTTP clients and Atom Feed handling implies
	that the resources and technical skills required for a successful		that the resources and technical skills required for a successful
	exploit may be less than it was previously. This risk can be best		exploit may be less than it was previously. This risk can be best
	mitigated through appropriate vetting of the client at account		mitigated through appropriate vetting of the client at account
	provisioning time. In addition, any increase in the risk of this		provisioning time. In addition, any increase in the risk of this
	type of abuse should be offset by the corresponding increase in		type of abuse should be offset by the corresponding increase in
	effectiveness that this specification affords to the defenders.		effectiveness that this specification affords to the defenders.
			Proper usage of TLS as described in Section 5.3 will in many cases
			aid in the mitigation of these issues.
	Overall, ROLIE introduces few privacy concerns above and beyond those		Overall, ROLIE introduces few privacy concerns above and beyond those
	present in any other HTTP protocol. Those that exist can be		present in any other HTTP protocol. Those that exist can be
	mitigated by following security considerations and carefully using		mitigated by following security considerations and carefully using
	the optional identifying elements.		the optional identifying elements.
	11. Acknowledgements		11. Acknowledgements
	The authors gratefully acknowledge the valuable contributions of Tom		The authors gratefully acknowledge the valuable contributions of Tom
	Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These		Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
	individuals provided detailed review comments on earlier drafts, and		individuals provided detailed review comments on earlier drafts, and
	made many suggestions that have helped to improve this document.		made many suggestions that have helped to improve this document.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[relax-NG]		[relax-NG]
	Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002,		Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002,
	<https://www.oasis-open.org/committees/relax-ng/compact-		<https://www.oasis-open.org/committees/relax-ng/
	20021121.html>.		compact-20021121.html>.
	[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,		[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
	RFC 20, DOI 10.17487/RFC0020, October 1969,		RFC 20, DOI 10.17487/RFC0020, October 1969,
	<http://www.rfc-editor.org/info/rfc20>.		<https://www.rfc-editor.org/info/rfc20>.
	[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>.		<https://www.rfc-editor.org/info/rfc2119>.
	[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>.		<https://www.rfc-editor.org/info/rfc3339>.
	[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An		[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
	IETF URN Sub-namespace for Registered Protocol		IETF URN Sub-namespace for Registered Protocol
	Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June		Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
	2003, <http://www.rfc-editor.org/info/rfc3553>.		2003, <https://www.rfc-editor.org/info/rfc3553>.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	DOI 10.17487/RFC3688, January 2004,		DOI 10.17487/RFC3688, January 2004,
	<http://www.rfc-editor.org/info/rfc3688>.		<https://www.rfc-editor.org/info/rfc3688>.
	[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", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, DOI 10.17487/RFC3986, January 2005,		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	<http://www.rfc-editor.org/info/rfc3986>.		<https://www.rfc-editor.org/info/rfc3986>.
	[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom		[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
	Syndication Format", RFC 4287, DOI 10.17487/RFC4287,		Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
	December 2005, <http://www.rfc-editor.org/info/rfc4287>.		December 2005, <https://www.rfc-editor.org/info/rfc4287>.
	[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using		[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using
	Transport Layer Security (TLS) with Network News Transfer		Transport Layer Security (TLS) with Network News Transfer
	Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October		Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
	2006, <http://www.rfc-editor.org/info/rfc4642>.		2006, <https://www.rfc-editor.org/info/rfc4642>.
	[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,		[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
	DOI 10.17487/RFC5005, September 2007,		DOI 10.17487/RFC5005, September 2007,
	<http://www.rfc-editor.org/info/rfc5005>.		<https://www.rfc-editor.org/info/rfc5005>.
	[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom		[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom
	Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,		Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023,
	October 2007, <http://www.rfc-editor.org/info/rfc5023>.		October 2007, <https://www.rfc-editor.org/info/rfc5023>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.
	[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, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<https://www.rfc-editor.org/info/rfc5280>.
	[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known		[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
	Uniform Resource Identifiers (URIs)", RFC 5785,		Uniform Resource Identifiers (URIs)", RFC 5785,
	DOI 10.17487/RFC5785, April 2010,		DOI 10.17487/RFC5785, April 2010,
	<http://www.rfc-editor.org/info/rfc5785>.		<https://www.rfc-editor.org/info/rfc5785>.
	[RFC6546] Trammell, B., "Transport of Real-time Inter-network		[RFC6546] Trammell, B., "Transport of Real-time Inter-network
	Defense (RID) Messages over HTTP/TLS", RFC 6546,		Defense (RID) Messages over HTTP/TLS", RFC 6546,
	DOI 10.17487/RFC6546, April 2012,		DOI 10.17487/RFC6546, April 2012,
	<http://www.rfc-editor.org/info/rfc6546>.		<https://www.rfc-editor.org/info/rfc6546>.
			[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
			"Recommendations for Secure Use of Transport Layer
			Security (TLS) and Datagram Transport Layer Security
			(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
			2015, <https://www.rfc-editor.org/info/rfc7525>.
	[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the		[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
	NETCONF Protocol over Transport Layer Security (TLS) with		NETCONF Protocol over Transport Layer Security (TLS) with
	Mutual X.509 Authentication", RFC 7589,		Mutual X.509 Authentication", RFC 7589,
	DOI 10.17487/RFC7589, June 2015,		DOI 10.17487/RFC7589, June 2015,
	<http://www.rfc-editor.org/info/rfc7589>.		<https://www.rfc-editor.org/info/rfc7589>.
	[RFC7970] Danyliw, R., "The Incident Object Description Exchange		[RFC7970] Danyliw, R., "The Incident Object Description Exchange
	Format Version 2", RFC 7970, DOI 10.17487/RFC7970,		Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
	November 2016, <http://www.rfc-editor.org/info/rfc7970>.		November 2016, <https://www.rfc-editor.org/info/rfc7970>.
			[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
			Writing an IANA Considerations Section in RFCs", BCP 26,
			RFC 8126, DOI 10.17487/RFC8126, June 2017,
			<https://www.rfc-editor.org/info/rfc8126>.
	[W3C.REC-xml-names-20091208]		[W3C.REC-xml-names-20091208]
	Bray, T., Hollander, D., Layman, A., Tobin, R., and H.		Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
	Thompson, "Namespaces in XML 1.0 (Third Edition)", World		Thompson, "Namespaces in XML 1.0 (Third Edition)", World
	Wide Web Consortium Recommendation REC-xml-names-20091208,		Wide Web Consortium Recommendation REC-xml-names-20091208,
	December 2009,		December 2009,
	<http://www.w3.org/TR/2009/REC-xml-names-20091208>.		<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
	12.2. Informative References		12.2. Informative References
	[REST] Fielding, R., "Architectural Styles and the Design of		[REST] Fielding, R., "Architectural Styles and the Design of
	Network-based Software Architectures", 2000,		Network-based Software Architectures", 2000,
	<http://www.ics.uci.edu/~fielding/pubs/dissertation/		<http://www.ics.uci.edu/~fielding/pubs/dissertation/
	top.htm>.		top.htm>.
	[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
	May 1997, <http://www.rfc-editor.org/info/rfc2141>.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	DOI 10.17487/RFC2782, February 2000,		DOI 10.17487/RFC2782, February 2000,
	<http://www.rfc-editor.org/info/rfc2782>.		<https://www.rfc-editor.org/info/rfc2782>.
			[RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible
			Markup Language) XML-Signature Syntax and Processing",
			RFC 3275, DOI 10.17487/RFC3275, March 2002,
			<https://www.rfc-editor.org/info/rfc3275>.
	[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between		[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
	Information Models and Data Models", RFC 3444,		Information Models and Data Models", RFC 3444,
	DOI 10.17487/RFC3444, January 2003,		DOI 10.17487/RFC3444, January 2003,
	<http://www.rfc-editor.org/info/rfc3444>.		<https://www.rfc-editor.org/info/rfc3444>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<http://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
			[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
			RFC 6749, DOI 10.17487/RFC6749, October 2012,
			<https://www.rfc-editor.org/info/rfc6749>.
			[RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin-
			Bound Authentication (HOBA)", RFC 7486,
			DOI 10.17487/RFC7486, March 2015,
			<https://www.rfc-editor.org/info/rfc7486>.
			[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
			Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
			2015, <https://www.rfc-editor.org/info/rfc7515>.
			[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
			RFC 7516, DOI 10.17487/RFC7516, May 2015,
			<https://www.rfc-editor.org/info/rfc7516>.
			[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
			Digest Access Authentication", RFC 7616,
			DOI 10.17487/RFC7616, September 2015,
			<https://www.rfc-editor.org/info/rfc7616>.
			[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
			RFC 7617, DOI 10.17487/RFC7617, September 2015,
			<https://www.rfc-editor.org/info/rfc7617>.
			[RFC7804] Melnikov, A., "Salted Challenge Response HTTP
			Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804,
			March 2016, <https://www.rfc-editor.org/info/rfc7804>.
			[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
			(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
			<https://www.rfc-editor.org/info/rfc8141>.
	[SAML-bind]		[SAML-bind]
	Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.		Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
	Maler, "Bindings for the OASIS Security Assertion Markup		Maler, "Bindings for the OASIS Security Assertion Markup
	Language (SAML) V2.0", OASIS Standard saml-bindings-		Language (SAML) V2.0", OASIS Standard saml-bindings-
	2.0-os, March 2005, <http://docs.oasis-		2.0-os, March 2005, <http://docs.oasis-
	open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.		open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.
	[SAML-core]		[SAML-core]
	Cantor, S., Kemp, J., Philpott, R., and E. Maler,		Cantor, S., Kemp, J., Philpott, R., and E. Maler,
	skipping to change at page 35, line 13 ¶		skipping to change at page 36, line 17 ¶
	open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>.		open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>.
	12.3. URIs		12.3. URIs
	[1] https://www.iana.org/assignments/link-relations/link-		[1] https://www.iana.org/assignments/link-relations/link-
	relations.xhtml		relations.xhtml
	[2] https://www.iana.org/assignments/link-relations/link-		[2] https://www.iana.org/assignments/link-relations/link-
	relations.xhtml		relations.xhtml
	[3] http://csrc.nist.gov/groups/SNS/rbac/		[3] https://www.iana.org/assignments/http-authschemes/http-
			authschemes.xhtml
			[4] http://csrc.nist.gov/groups/SNS/rbac/
	Appendix A. Relax NG Compact Schema for ROLIE		Appendix A. Relax NG Compact Schema for ROLIE
	This appendix is informative.		This appendix is informative.
	The Relax NG schema below defines the rolie:format element.		The Relax NG schema below defines the rolie:format element.
	# -*- rnc -*-		# -*- rnc -*-
	# RELAX NG Compact Syntax Grammar for the rolie ns		# RELAX NG Compact Syntax Grammar for the rolie ns
	skipping to change at page 42, line 7 ¶		skipping to change at page 43, line 7 ¶
	src="http://www.example.org/provider/vulns/123456/data">		src="http://www.example.org/provider/vulns/123456/data">
	</content>		</content>
	</entry>		</entry>
	The example response above shows an XML document referenced by the		The example response above shows an XML document referenced by the
	"src" attribute of the atom:content element. The client may retrieve		"src" attribute of the atom:content element. The client may retrieve
	the document using this URL.		the document using this URL.
	Appendix C. Change History		Appendix C. Change History
			Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08
			revision:
			TLS requirements changed to clarify TLS versioning and
			recommendations
			Informative references and textual discussion added to Security
			Considerations around HTTP Authentication and content Signing/
			Encryption.
			IANA Expert review clarified.
			Editorial changes from AD review/WGLC.
	Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07		Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07
	revision:		revision:
	Reworked "usage of app:collection" and "usage of atom:feed"		Reworked "usage of app:collection" and "usage of atom:feed"
	sections to clarify ROLIE vs non-ROLIE collections/feeds		sections to clarify ROLIE vs non-ROLIE collections/feeds
	Removed requirement from Security Considerations that was a		Removed requirement from Security Considerations that was a
	duplicate of text earlier in the document		duplicate of text earlier in the document
	TLS requirement clarifications around mutal authentication		TLS requirement clarifications around mutal authentication
	skipping to change at page 45, line 4 ¶		skipping to change at page 46, line 18 ¶
	Authors' Addresses		Authors' Addresses
	John P. Field		John P. Field
	Pivotal Software, Inc.		Pivotal Software, Inc.
	625 Avenue of the Americas		625 Avenue of the Americas
	New York, New York		New York, New York
	USA		USA
	Phone: (646)792-5770		Phone: (646)792-5770
	Email: jfield@pivotal.io		Email: jfield@pivotal.io
	Stephen A. Banghart		Stephen A. Banghart
	National Institute of Standards and Technology		National Institute of Standards and Technology
	100 Bureau Drive		100 Bureau Drive
	Gaithersburg, Maryland		Gaithersburg, Maryland
	USA		USA
	Phone: (301)975-4288		Phone: (301)975-4288
	Email: sab3@nist.gov		Email: stephen.banghart@nist.gov
	David Waltermire		David Waltermire
	National Institute of Standards and Technology		National Institute of Standards and Technology
	100 Bureau Drive		100 Bureau Drive
	Gaithersburg, Maryland 20877		Gaithersburg, Maryland 20877
	USA		USA
	Email: david.waltermire@nist.gov		Email: david.waltermire@nist.gov
End of changes. 51 change blocks.
	90 lines changed or deleted		173 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/