draft-ietf-mile-rolie-10.txt		draft-ietf-mile-rolie-11.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: April 1, 2018 D. Waltermire		Expires: April 22, 2018 D. Waltermire
	NIST		NIST
	September 28, 2017		October 19, 2017
	Resource-Oriented Lightweight Information Exchange		Resource-Oriented Lightweight Information Exchange
	draft-ietf-mile-rolie-10		draft-ietf-mile-rolie-11
	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 2, line 4 ¶		skipping to change at page 2, line 4 ¶
	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 https://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 April 1, 2018.		This Internet-Draft will expire on April 22, 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
	(https://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
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4		3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4
	3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4		3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4
	3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5		3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5
	4. Background and Motivation . . . . . . . . . . . . . . . . . . 5		4. Background and Motivation . . . . . . . . . . . . . . . . . . 5
	5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6		5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6
	5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7		5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7
	5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7		5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7
	5.1.2. Use of the "app:collection" Element . . . . . . . . . 8		5.1.2. Use of the "app:collection" Element . . . . . . . . . 8
	5.1.3. Service Discovery . . . . . . . . . . . . . . . . . . 9		5.1.3. Service Document Discovery . . . . . . . . . . . . . 9
	5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9		5.2. Category Documents . . . . . . . . . . . . . . . . . . . 9
	5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10		5.3. Transport Layer Security . . . . . . . . . . . . . . . . 9
	5.4. User Authentication and Authorization . . . . . . . . . . 11		5.4. User Authentication and Authorization . . . . . . . . . . 10
	5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11		5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 10
	5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12		5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11
	6. ROLIE Requirements for the Atom Syndication Format . . . . . 12		6. ROLIE Requirements for the Atom Syndication Format . . . . . 11
	6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12		6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 11
	6.1.1. Use of the "atom:category" Element . . . . . . . . . 13		6.1.1. Use of the "atom:category" Element . . . . . . . . . 12
	6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14		6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 13
	6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15		6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 14
	6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15		6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 14
	6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16		6.2.1. Use of the "atom:content" Element . . . . . . . . . . 15
	6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 17		6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16
	6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17		6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 16
	6.2.4. Use of the rolie:property Element . . . . . . . . . . 18		6.2.4. Use of the rolie:property Element . . . . . . . . . . 17
	6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19		6.2.5. Requirements for a Standalone Entry . . . . . . . . . 18
	7. Available Extension Points Provided by ROLIE . . . . . . . . 20		7. Available Extension Points Provided by ROLIE . . . . . . . . 19
	7.1. The Category Extension Point . . . . . . . . . . . . . . 20		7.1. The Category Extension Point . . . . . . . . . . . . . . 19
	7.1.1. General Use of the "atom:category" Element . . . . . 21		7.1.1. General Use of the "atom:category" Element . . . . . 20
	7.1.2. Identification of Security Automation Information		7.1.2. Identification of Security Automation Information
	Types . . . . . . . . . . . . . . . . . . . . . . . . 21		Types . . . . . . . . . . . . . . . . . . . . . . . . 20
	7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22		7.2. The "rolie:format" Extension Point . . . . . . . . . . . 21
	7.3. The Link Relation Extension Point . . . . . . . . . . . . 23		7.3. The Link Relation Extension Point . . . . . . . . . . . . 22
	7.4. The "rolie:property" Extension Point . . . . . . . . . . 23		7.4. The "rolie:property" Extension Point . . . . . . . . . . 22
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
	8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24		8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23
	8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25		8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 24
	8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25		8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24
	8.4. ROLIE Security Resource Information Type Sub-Registry . . 28		8.4. ROLIE Security Resource Information Type Sub-Registry . . 26
	8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28		8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 27
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 29		9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
	10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31		10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12.1. Normative References . . . . . . . . . . . . . . . . . . 32		12.1. Normative References . . . . . . . . . . . . . . . . . . 30
	12.2. Informative References . . . . . . . . . . . . . . . . . 34		12.2. Informative References . . . . . . . . . . . . . . . . . 33
	12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36		12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
	Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 36		Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35
	Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 37		Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36
	B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 37		B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36
	B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 40		B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39
	B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 42		B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41
	Appendix C. Change History . . . . . . . . . . . . . . . . . . . 43		Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
	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 5, line 29 ¶		skipping to change at page 5, line 29 ¶
	"http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom"		"http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom"
	namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287		namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287
	appendix B [RFC4287] respectively.		appendix B [RFC4287] respectively.
	A complete informative RELAX NG Compact Schema for the new elements		A complete informative RELAX NG Compact Schema for the new elements
	introduced by ROLIE is provided in Appendix A.		introduced by ROLIE is provided in Appendix A.
	4. Background and Motivation		4. Background and Motivation
	In order to automate security process, tools need access to		In order to automate security process, tools need access to
	sufficient sources of structured, security information that can be		sufficient sources of structured security information that can be
	used to drive security processes. Thus, security information sharing		used to drive security processes. Thus, security information sharing
	is one of the core components of automating security processes.		is one of the core components of automating security processes.
	Vulnerabilities, configurations, software identification, security		Vulnerabilities, configurations, software identification, security
	incidents, and patch data are just a few of the classes of		incidents, and patch data are just a few of the classes of
	information that are shared today to enable effective security on a		information that are shared today to enable effective security on a
	wide scale. However, as the scale of defense broadens as networks		wide scale. However, as the scale of defense broadens as networks
	become larger and more complex, and the volume of information to		become larger and more complex, and the volume of information to
	process makes humans-in-the-loop difficult to scale, the need for		process makes humans-in-the-loop difficult to scale, the need for
	automation and machine-to-machine communication becomes increasingly		automation and machine-to-machine communication becomes increasingly
	critical.		critical.
	skipping to change at page 7, line 50 ¶		skipping to change at page 7, line 50 ¶
	In AtomPub, a Workspace, represented by the "app:workspace" element,		In AtomPub, a Workspace, represented by the "app:workspace" element,
	describes a group of one or more Collections. Building on the		describes a group of one or more Collections. Building on the
	AtomPub concept of a Workspace, in ROLIE a Workspace represents an		AtomPub concept of a Workspace, in ROLIE a Workspace represents an
	aggregation of Collections pertaining to security automation		aggregation of Collections pertaining to security automation
	information resources. This specification does not restrict the		information resources. This specification does not restrict the
	number of Workspaces that may be in a Service Document or the		number of Workspaces that may be in a Service Document or the
	specific Collections to be provided within a given Workspace.		specific Collections to be provided within a given Workspace.
	A ROLIE implementation can host Collections containing both public		A ROLIE implementation can host Collections containing both public
	and private information entries. It is RECOMMENDED that		and private information entries. It is suggested that
	implementations segregate public and private Collections into		implementations segregate Collections into different app:workspace
	different app:workspace elements. By doing this, Workspaces that		elements by their client access requirements. With proper naming of
	contain private information can be ignored by clients or can be		workspaces, this reduces the amount of trial and error a human user
	omitted from the Service Document provided to a client that lacks the		would need to utilize to discover accessible Collections.
	appropriate privilege to access the set of Collections associated
	with the Workspace.
	5.1.2. Use of the "app:collection" Element		5.1.2. Use of the "app:collection" Element
	In AtomPub, a Collection in a Service Document, represented by the		In AtomPub, a Collection in a Service Document, represented by the
	"app:collection" element, provides metadata that can be used to point		"app:collection" element, provides metadata that can be used to point
	to a specific Atom Feed that contains information Entries that may be		to a specific Atom Feed that contains information Entries that may be
	of interest to a client. The association between a Collection and a		of interest to a client. The association between a Collection and a
	Feed is provided by the "href" attribute of the app:collection		Feed is provided by the "href" attribute of the app:collection
	element. Building on the AtomPub concept of a Collection, in ROLIE a		element. Building on the AtomPub concept of a Collection, in ROLIE a
	Collection represents a pointer to a group of security automation		Collection represents a pointer to a group of security automation
	skipping to change at page 9, line 17 ¶		skipping to change at page 9, line 13 ¶
	Atom Feed resource referenced by the app:collection "href"		Atom Feed resource referenced by the app:collection "href"
	attribute value. This ensures that the category metadata		attribute value. This ensures that the category metadata
	associated with the Collection and the associated Feed is		associated with the Collection and the associated Feed is
	discoverable in both of these resources.		discoverable in both of these resources.
	o The app:categories element in an app:collection MAY include		o The app:categories element in an app:collection MAY include
	additional atom:category elements using a scheme other than		additional atom:category elements using a scheme other than
	"urn:ietf:params:rolie:category:information-type". This allows		"urn:ietf:params:rolie:category:information-type". This allows
	other category metadata to be included.		other category metadata to be included.
	5.1.3. Service Discovery		5.1.3. Service Document Discovery
	This specification requires that an implementation MUST publish an		..his specification requires that an implementation MUST publish an
	Atom Service Document that describes the set of security information		Atom Service Document that describes the set of security information
	Collections provided by the service. The Service Document MUST be		Collections provided by the service. The Service Document MUST be
	retrievable using the standardized URI template		retrievable using the standardized URI template
	"https://{host:port}/.well-known/rolie/servicedocument", where		"https://{host:port}/.well-known/rolie/servicedocument", where
	{host:port} is the authority portion of the URI. Dereferencing this		{host:port} is the authority portion of the URI. Dereferencing this
	URI MAY result in a redirect based on an appropriate HTTP 3xx status		URI MAY result in a redirect based on an appropriate HTTP 3xx status
	code to direct the client to the actual Service Document. This		code to direct the client to the actual Service Document. This
	allows clients to have a well-known location to find a ROLIE service		allows clients to have a well-known location to find a ROLIE service
	document, while giving implementations flexibility over how the		document, while giving implementations flexibility over how the
	service is deployed.		service is deployed.
	This document registers the "rolie/servicedocument" well-known URI as		This document registers the "rolie/servicedocument" well-known URI as
	per [RFC5785] in Section 8.5.		per [RFC5785] in Section 8.5.
	A mechanism to determine which host and port to use is not specified		A mechanism to determine which host and port to use is not specified
	in this document. Use of a mechanism such as DNS SRV Records		in this document. Use of a mechanism such as DNS SRV Records
	[RFC2782] can provide a secure and reliable discovery mechanism for		[RFC2782] can provide a secure and reliable discovery mechanism for
	determining a specific host and port to use for retrieving a Service		determining a specific host and port to use for retrieving a Service
	Document for a given DNS domain.		Document for a given DNS domain.
	5.2. AtomPub Category Documents		5.2. Category Documents
	As described in RFC5023 section 7 [RFC5023], a Category Document is		As described in RFC5023 section 7 [RFC5023], a Category Document is
	an XML-based document format that allows a client to dynamically		an XML-based document format that allows a client to dynamically
	discover the Categories used within AtomPub Service Documents, and		discover the Categories used within AtomPub Service Documents, Atom
	Atom Syndication Feed and Entry documents provided by a publisher. A		Syndication Feeds, and Entry documents provided by a publisher. A
	Category Document consists of one app:categories element that		Category Document consists of one app:categories element that
	contains a number of inline atom:category elements, or a URI		contains a number of inline atom:category elements, or a URI
	referencing a Category Document.		referencing a Category Document.
	A ROLIE implementation MUST publish a Category Document that
	describes the set of atom:category elements and associated terms
	currently used by the service.
	The Category Document MUST be retrievable using the standardized URI
	template "https://{host:port}/.well-known/rolie/categorydocument",
	where {host:port} is the authority portion of the URI. Dereferencing
	this URI MAY result in a redirect based on an appropriate HTTP 3xx
	status code to direct the client to the actual Category Document.
	This allows clients to have a well-known location to find a ROLIE
	category document, while giving implementations flexibility over how
	the service is deployed.
	This document registers the "rolie/categorydocument" well-known URI
	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. TLS version 1.2 MUST be
	have been in part derived from [RFC7589].		supported. TLS 1.2 SHOULD be implemented according to all
			recommendations and best practices present in [RFC7525].
	TLS version 1.2 MUST be supported. TLS 1.2 SHOULD be implemented
	according to all recommendations and best practices present in
	[RFC7525].
	It is RECOMMENDED that the most recent published version of TLS is		It is RECOMMENDED that the most recent published version of TLS is
	supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is		supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is
	recommended that 0-RTT (Zero Round Trip Time Resumption) is not used,		recommended that 0-RTT (Zero Round Trip Time Resumption) is not used,
	as there is a replay attack that is possible with that option.		as there is a replay attack that is possible with that option.
	The server MUST support certificate-based client authentication. An		The server MUST implement certificate-based client authentication.
	implementation MUST support the set of TLS cipher suites that are		This MAY be enabled on a workspace by workspace basis.
	REQUIRED by the latest published version of the TLS specification.
	An implementation MUST also support the TLS cipher suites that
	provide support for mutual authentication of clients and servers.
	During the TLS negotiation, the client MUST carefully examine the
	certificate presented by the server to determine if it meets the
	client's expectations. Particularly, the client MUST check its
	understanding of the server hostname against the server's identity as
	presented in the server Certificate message, in order to prevent man-
	in-the-middle attacks. Matching is performed according to the rules
	laid out in the Security Considerations section of [RFC4642]. If the
	match fails, the client MUST either ask for explicit user
	confirmation or terminate the connection and indicate the server's
	identity is suspect. If the client has external information as to
	the expected identity of the server, the hostname check MAY be
	omitted.
	Clients MUST verify the binding between the identity of the servers
	to which they connect and the public keys presented by those servers.
	Client implementations SHOULD support a certificate validation
	approach based on section 6 of [RFC5280].
	The server MUST be capable of verifying the identity of the client
	with certificate-based authentication according to local policy to
	ensure that the incoming client request is legitimate before any
	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, or Workspace by Workspace 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.
	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,		support 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
	deployments that are using Transport of Real-time Inter-network		deployments that are using Transport of Real-time Inter-network
	Defense (RID) Messages over HTTP/TLS [RFC6546].		Defense (RID) Messages over HTTP/TLS [RFC6546].
	The following additional requirements apply for implementations		The following additional requirements only apply if a implementation
	supporting handling of the "/" resource::		is supporting the "/" resource as described above:
	o Consistent with RFC6546 errata, a client requesting a GET on the		o Consistent with RFC6546 errata, a client requesting a GET on the
	"/" resource SHOULD receive an HTTP status code 405 Method Not		"/" resource SHOULD receive an HTTP status code 405 Method Not
	Allowed.		Allowed.
	o An implementation MAY provide full support for [RFC6546] such that		o An implementation MAY provide full support for [RFC6546] such that
	a POST to the "/" resource containing a recognized RID message is		a POST to the "/" resource containing a recognized RID message is
	handled correctly as a RID request. Alternatively, a client		handled correctly as a RID request. Alternatively, a client
	requesting a POST to "/" MAY receive an HTTP status code 307		requesting a POST to "/" MAY receive an HTTP status code 307
	Temporary Redirect. In this case, the location header in the HTTP		Temporary Redirect. In this case, the location header in the HTTP
	response will provide the URL of the appropriate RID endpoint, and		response will provide the URL of the appropriate RID endpoint, and
	the client may repeat the POST method at the indicated location.		the client may repeat the POST method at the indicated location.
	If the "/" resource is unsupported, then a request for this resource		If the "/" resource is unsupported, then a request for this resource
	MUST provide a 404 HTTP status code.		MAY be handled as deemed appropriate by the server.
	5.6. HTTP methods		5.6. HTTP methods
	Servers MAY accept request methods beyond those specified in this		Servers MAY accept request methods beyond those specified in this
	document.		document.
	Clients MUST be capable of recognizing and processing any standard		Clients MUST be capable of recognizing and processing any standard
	HTTP status code, as defined in [RFC5023] Section 5.		HTTP status code, as defined in [RFC5023] Section 5.
	6. ROLIE Requirements for the Atom Syndication Format		6. ROLIE Requirements for the Atom Syndication Format
	skipping to change at page 13, line 45 ¶		skipping to change at page 12, line 45 ¶
	& atomTitle		& atomTitle
	& atomUpdated		& atomUpdated
	& extensionElement*),		& extensionElement*),
	atomEntry*		atomEntry*
	}		}
	The following subsections contain requirements for a ROLIE Feed.		The following subsections contain requirements for a ROLIE Feed.
	6.1.1. Use of the "atom:category" Element		6.1.1. Use of the "atom:category" Element
	An atom:feed can contain zero or more atom:category elements. In		An atom:feed can contain one or more atom:category elements. In Atom
	Atom the naming scheme and the semantic meaning of the terms used to		the naming scheme and the semantic meaning of the terms used to
	identify an Atom category are application-defined.		identify an Atom category are application-defined.
	The following are additional requirements on the use of the		The following are additional requirements on the use of the
	atom:category element when used in a ROLIE Feed:		atom:category element when used in a ROLIE Feed:
	o All member Entries in the Feed MUST represent security automation		o All member Entries in the Feed MUST represent security automation
	information records of the provided information type category.		information records of the provided information type category.
	o An atom:feed MAY include additional atom:category elements using a		o An atom:feed MAY include additional atom:category elements using a
	scheme other than "urn:ietf:params:rolie:category:information-		scheme other than "urn:ietf:params:rolie:category:information-
	skipping to change at page 15, line 38 ¶		skipping to change at page 14, line 38 ¶
	An atom:feed MAY include additional link relationships not specified		An atom:feed MAY include additional link relationships not specified
	in this document. If a client encounters an unknown link		in this document. If a client encounters an unknown link
	relationship type, the client MUST ignore the unrecognized link and		relationship type, the client MUST ignore the unrecognized link and
	continue processing as if the unrecognized link element did not		continue processing as if the unrecognized link element did not
	appear. The definition of new Link relations that provide additional		appear. The definition of new Link relations that provide additional
	state transition extensions is discussed in section 7.3.		state transition extensions is discussed in section 7.3.
	6.1.3. Use of the "atom:updated" Element		6.1.3. Use of the "atom:updated" Element
	The atom:updated element identifies the date and time that an Entry		The atom:updated element identifies the date and time that a Feed was
	was last updated.		last updated.
	The atom:updated element MUST be populated with the current time at		The atom:updated element MUST be populated with the current time at
	the instant the Feed representation was last updated by adding,		the instant the Feed was last updated by adding, updating, or
	updating, or deleting an Entry; or changing any metadata for the		deleting an Entry; or changing any metadata for the Feed.
	Feed.
	6.2. Use of the "atom:entry" Element		6.2. Use of the "atom:entry" Element
	Each Entry in an Atom Feed, represented by the atom:entry element,		Each Entry in an Atom Feed, represented by the atom:entry element,
	describes a single referenced information record, along with		describes a single referenced information record, along with
	descriptive information about its format, media type, and other		descriptive information about its format, media type, and other
	publication metadata. The following atom:entry schema definition		publication metadata. The following atom:entry schema definition
	represents a stricter representation of the atom:entry element		represents a stricter representation of the atom:entry element
	defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in		defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in
	section 6.1.1.		section 6.1.1.
	skipping to change at page 16, line 27 ¶		skipping to change at page 15, line 27 ¶
	& atomRights?		& atomRights?
	& atomSource?		& atomSource?
	& atomSummary?		& atomSummary?
	& atomTitle		& atomTitle
	& atomUpdated		& atomUpdated
	& rolieFormat		& rolieFormat
	& rolieProperty*		& rolieProperty*
	& extensionElement*)		& extensionElement*)
	}		}
			The notable changes from [RFC4287] are the addition of rolieFormat
			and rolieProperty, and atomContent no longer being optional.
	The following subsections contain requirements for Entries in a ROLIE		The following subsections contain requirements for Entries in a ROLIE
	Feed.		Feed.
	6.2.1. Use of the "atom:content" Element		6.2.1. Use of the "atom:content" Element
	An atom:content element associates its containing Entry with a		An atom:content element associates its containing Entry with a
	content resource identified by the src attribute.		content resource identified by the src attribute.
	There MUST be exactly one atom:content element in the Entry. The		There MUST be exactly one atom:content element in the Entry. The
	content element MUST adhere to this definition, which is a stricter		content element MUST adhere to this definition, which is a stricter
	representation of the atom:content element defined in [RFC4287]:		representation of the atom:content element defined in [RFC4287]:
	atomContent =		atomContent =
	element atom:content {		element atom:content {
	atomCommonAttributes,		atomCommonAttributes,
	attribute type { atomMediaType },		attribute type { atomMediaType },
	attribute src { atomUri },		attribute src { atomUri },
	empty		empty
	}		}
			This restricts atomContent in ROLIE to the atomOutofLine forumulation
			presented in[RFC4287].
	The type attribute MUST identify the serialization type of the		The type attribute MUST identify the serialization type of the
	content, for example, application/xml or application/json. A		content, for example, application/xml or application/json. A
	prefixed media type MAY be used to reflect a specific model used with		prefixed media type MAY be used to reflect a specific model used with
	a given serialization approach (e.g., application/rdf+xml). The src		a given serialization approach (e.g., application/rdf+xml). The src
	attribute MUST be an IRI that can be dereferenced to retrieve the		attribute MUST be an IRI that can be dereferenced to retrieve the
	related content data.		related content data.
	6.2.2. Use of the "atom:link" Element		6.2.2. Use of the "atom:link" Element
	Link relations can be included in an atom:entry to represent state		Link relations can be included in an atom:entry to represent state
	skipping to change at page 20, line 45 ¶		skipping to change at page 19, line 45 ¶
	ROLIE further defines the use of the existing Atom extension category		ROLIE further defines the use of the existing Atom extension category
	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		Any category whose "scheme" attribute uses an unregistered scheme
	reserved in the IANA ROLIE Parameters table for private use as		MUST be considered private use. Implementations encountering such a
	defined in [RFC8126]. Any category whose "scheme" attribute uses		category MUST parse the content without error, but MAY otherwise
	this as a prefix MUST be considered private use. Implementations		ignore the element.
	encountering such a category MUST parse the content without error,
	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
	Resource. As discussed earlier in this document, an atom:category		Resource. As discussed earlier in this document, an atom:category
	element has a "term" attribute that indicates the assigned category		element has a "term" attribute that indicates the assigned category
	value, and a "scheme" attribute that provides an identifier for the		value, and a "scheme" attribute that provides an identifier for the
	skipping to change at page 22, line 11 ¶		skipping to change at page 21, line 7 ¶
	For example, the notional security automation information type		For example, the notional security automation information type
	"incident" would be identified as follows:		"incident" would be identified as follows:
	<atom:category		<atom:category
	scheme="urn:ietf:params:rolie:category:information-type"		scheme="urn:ietf:params:rolie:category:information-type"
	term="incident"/>		term="incident"/>
	A security automation information type represents a class of		A security automation information type represents a class of
	information that represents the same or similar information model		information that represents the same or similar information model
	[RFC3444]. Notional examples of information types include:		[RFC3444]. Note that this document does not register any information
			types, but offers the following as examples of potential information
			types:
	indicator: Computing device- or network-related "observable features		indicator: Computing device- or network-related "observable features
	and phenomenon that aid in the forensic or proactive detection of		and phenomenon that aid in the forensic or proactive detection of
	malicious activity; and associated meta-data" (from [RFC7970]).		malicious activity; and associated meta-data" (from [RFC7970]).
	incident: Information pertaining to and "derived analysis from		incident: Information pertaining to and "derived analysis from
	security incidents" (from [RFC7970]).		security incidents" (from [RFC7970]).
	vulnerability reports: Information identifying and describing a		vulnerability reports: Information identifying and describing a
	vulnerability in hardware or software.		vulnerability in hardware or software.
	skipping to change at page 24, line 5 ¶		skipping to change at page 22, line 50 ¶
	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
	individual or organization that authored the content referenced by		individual or organization that authored the content referenced by
	the "src" attribute of the entry's atom:content element.		the "src" attribute of the entry's atom:content element. This
			author may differ from the atom:author when the author of the
			content and the entry are different people or entities.
	urn:ietf:params:rolie:property:content-id The "value" attribute of		urn:ietf:params:rolie:property:content-id The "value" attribute of
	this property is a text representation of an identifier pertaining		this property is a text representation of an identifier pertaining
	to or extracted from the content referenced by the "src" attribute		to or extracted from the content referenced by the "src" attribute
	of the entry's atom:content element.		of the entry's atom:content element.
	urn:ietf:params:rolie:property:content-published-date The "value"		urn:ietf:params:rolie:property:content-published-date The "value"
	attribute of this property is a text representation indicating the		attribute of this property is a text representation indicating the
	original publication date of the content referenced by the "src"		original publication date of the content referenced by the "src"
	attribute of the entry's atom:content element. This date may		attribute of the entry's atom:content element. This date may
	skipping to change at page 27, line 22 ¶		skipping to change at page 26, line 22 ¶
	| | | Secti | following location: htt |		| | | Secti | following location: htt |
	| | | on | ps://www.iana.org/assig |		| | | on | ps://www.iana.org/assig |
	| | | 8.4 | nments/rolie/category |		| | | 8.4 | nments/rolie/category |
	| | | | /information-type] |		| | | | /information-type] |
	| property:l | urn:ietf:params:ro | This | None |		| property:l | urn:ietf:params:ro | This | None |
	| ocal | lie:property:local | docum | |		| ocal | lie:property:local | docum | |
	| | | ent, | |		| | | ent, | |
	| | | Secti | |		| | | Secti | |
	| | | on | |		| | | on | |
	| | | 7.4 | |		| | | 7.4 | |
	| category:l | urn:ietf:params:ro | This | None |
	| ocal | lie:category:local | docum | |
	| | | ent, | |
	| | | Secti | |
	| | | on | |
	| | | 7.1 | |
	| property | urn:ietf:params:ro | This | None |		| property | urn:ietf:params:ro | This | None |
	| :content- | lie:property | docum | |		| :content- | lie:property | docum | |
	| author- | :content-author- | ent, | |		| author- | :content-author- | ent, | |
	| name | name | Secti | |		| name | name | Secti | |
	| | | on | |		| | | on | |
	| | | 7.4 | |		| | | 7.4 | |
	| property | urn:ietf:params:ro | This | None |		| property | urn:ietf:params:ro | This | None |
	| :content- | lie:property | docum | |		| :content- | lie:property | docum | |
	| id | :content-id | ent, | |		| id | :content-id | ent, | |
	| | | Secti | |		| | | Secti | |
	skipping to change at page 28, line 19 ¶		skipping to change at page 27, line 14 ¶
	Name of Registry: "ROLIE Information Types"		Name of Registry: "ROLIE Information Types"
	Location of Registry:		Location of Registry:
	https://www.iana.org/assignments/rolie/category/information-type		https://www.iana.org/assignments/rolie/category/information-type
	Fields to record in the registry:		Fields to record in the registry:
	name: The full name of the security resource information type		name: The full name of the security resource information type
	as a string from the printable ASCII character set [RFC0020]		as a string from the printable ASCII character set [RFC0020]
	with individual embedded spaces allowed. The ABNF [RFC5234]		with individual embedded spaces allowed. This value must be
	syntax for this field is:		unique in the context of this table. The ABNF [RFC5234] syntax
			for this field is:
	1*VCHAR *(SP 1*VCHAR)		1*VCHAR *(SP 1*VCHAR)
	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
	skipping to change at page 28, line 52 ¶		skipping to change at page 27, line 48 ¶
	Service Document registration:		Service Document registration:
	URI suffix: rolie/servicedocument		URI suffix: rolie/servicedocument
	Change controller: IETF		Change controller: IETF
	Specification document: This document, Section 5.1.3		Specification document: This document, Section 5.1.3
	Related information: None		Related information: None
	Category Document registration:
	URI suffix: rolie/categorydocument
	Change controller: IETF
	Specification document: This document, Section 5.2
	Related information: None
	9. Security Considerations		9. Security Considerations
	This document defines a resource-oriented approach for lightweight		This document defines a resource-oriented approach for lightweight
	information exchange using HTTP over TLS, the Atom Syndication		information exchange using HTTP over TLS, the Atom Syndication
	Format, and the Atom Publishing Protocol. As such, implementers must		Format, and the Atom Publishing Protocol. As such, implementers must
	understand the security considerations described in those		understand the security considerations described in those
	specifications. All that follows is guidance, more specific		specifications. All that follows is guidance, more specific
	instruction is out of scope for this document.		instruction is out of scope for this document.
	To protect the confidentiality of a given resource provided by a		To protect the confidentiality of a given resource provided by a
	ROLIE implementation, requests for retrieval of the resource need to		ROLIE implementation, requests for retrieval of the resource need to
	be authenticated to prevent unauthorized users from accessing the		be authenticated to prevent unauthorized users from accessing the
	resource (see section 5.4). It can also be useful to log and audit		resource (see section 5.4). It can also be useful to log and audit
	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		Access control to information published using ROLIE should use
	being implemented at the point when a resource representation is		mechanisms that are appropriate to the sensitivity of the
	created. As such, producers sharing cyber security information using		information. Primitive authentication mechanisms like HTTP Basic
	this specification must take care to authenticate their HTTP clients		Authentication [RFC7617] are rarely appropriate for sensitive
	using a suitably strong user authentication mechanism. Sharing		information. A number of authentication schemes are defined in the
	communities that are exchanging information on well-known indicators		HTTP Authentication Schemes Registry [3]. Of these, HOBA [RFC7486]
	and incidents for purposes of public education may choose to rely		and SCRAM-SHA-256 [RFC7804] provide improved security properties over
	upon HTTP Authentication or similar. A number of authentication		HTTP Basic [RFC7617]and Digest [RFC7616] Authentication Schemes.
	schemes are defined in the HTTP Authentication Schemes Registry [3].		However, sharing communities that are engaged in sensitive
	Of these, HOBA [RFC7486] and SCRAM-SHA-256 [RFC7804] provide improved		collaborative analysis and/or operational response for indicators and
	security properties over HTTP Basic [RFC7617]and Digest [RFC7616]		incidents targeting high value information systems should adopt a
	Authentication Schemes. However, sharing communities that are		suitably stronger user authentication solution, such as a risk-based
	engaged in sensitive collaborative analysis and/or operational		or multi-factor approach.
	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
	approach. In general, trust in the sharing consortium will depend
	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 OAuth [RFC6749]		federated identity solution, such as those based upon OAuth [RFC6749]
	with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind],		with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind],
	and SAML-prof [SAML-prof] for Web-based authentication and cross-		and SAML-prof [SAML-prof] for Web-based authentication and cross-
	organizational single sign-on. Dependency on a trusted third party		organizational single sign-on. Dependency on a trusted third party
	identity provider implies that appropriate care must be exercised to		identity provider implies that appropriate care must be exercised to
	sufficiently secure the Identity provider. Any attacks on the		sufficiently secure the Identity provider. Any attacks on the
	federated identity system would present a risk to the consortium, as		federated identity system would present a risk to the consortium, as
	a relying party. Potential mitigations include deployment of a		a relying party. Potential mitigations include deployment of a
	skipping to change at page 30, line 33 ¶		skipping to change at page 29, line 15 ¶
	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. Additionally, the		Refer to RFC6545 section 9 for more information. Additionally, the
	underlying serialization approach used in the message (e.g., XML,		underlying serialization approach used in the representation (e.g.,
	JSON) can offer encryption and message authentication capabilities.		XML, JSON) can offer encryption and message authentication
	For example, XMLDSig [RFC3275] for XML, and JSON Web Encryption		capabilities. For example, XMLDSig [RFC3275] for XML, and JSON Web
	[RFC7516] and JSON Web Signature[RFC7515] for JSON can provide such		Encryption [RFC7516] and JSON Web Signature[RFC7515] for JSON can
	mechanisms.		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
	to better coordinate and align their respective policy expressions.		to better coordinate and align their respective policy expressions.
	A service discovery mechanism is not explicitly specified in this		A service discovery mechanism is not explicitly specified in this
	document, and there are several approaches available for		document, and there are several approaches available for
	implementers. When selecting this mechanism, implementations need to		implementers. When selecting this mechanism, implementations need to
	ensure that their choice provides a means for authenticating the		ensure that their choice provides a means for authenticating the
	server. As described in the discovery section, DNS SRV Records are a		server. As described in the discovery section, DNS SRV Records are a
	possible secure solution to discovery.		possible solution to discovery.
	10. Privacy Considerations		10. Privacy Considerations
	The optional author field may provide an identification privacy issue		The optional author field may provide an identification privacy issue
	if populated without the author's consent. This information may		if populated without the author's consent. This information may
	become public if posted to a public feed. Special care should be		become public if posted to a public feed. Special care should be
	taken when aggregating or sharing entries from other feeds, or when		taken when aggregating or sharing entries from other feeds, or when
	programmatically generating ROLIE entries from some data source that		programmatically generating ROLIE entries from some data source that
	the author's personal info is not shared without their consent.		the author's personal info is not shared without their consent.
	When using the Atom Publishing Protocol to POST entries to a feed,		When using the Atom Publishing Protocol to POST entries to a feed,
	attackers may use correlating techniques to profile the user. The		attackers may use correlating techniques to profile the user. The
	request time can be compared to the generated "updated" field of the		request time can be compared to the generated "updated" field of the
	entry in order to build out information about a given user. This		entry in order to build out information about a given user. This
	correlation attempt can be mitigated by not using HTTP requests to		correlation attempt can be mitigated by not using HTTP requests to
	POST entries when profiling is a risk, and rather use backend control		POST entries when profiling is a risk, and rather use backend control
	of the feeds.		of the Feeds.
	Adoption of the information sharing approach described in this		Adoption of the information sharing approach described in this
	document will enable users to more easily perform correlations across		document will enable users to more easily perform correlations across
	separate, and potentially unrelated, cyber security information		separate, and potentially unrelated, cyber security information
	providers. A client may succeed in assembling a data set that would		providers. A client may succeed in assembling a data set that would
	not have been permitted within the context of the authorization		not have been permitted within the context of the authorization
	policies of either provider when considered individually. Thus,		policies of either provider when considered individually. Thus,
	providers may face a risk of an attacker obtaining an access that		providers may face a risk of an attacker obtaining an access that
	constitutes an undetected separation of duties (SOD) violation. It		constitutes an undetected separation of duties (SOD) violation. It
	is important to note that this risk is not unique to this		is important to note that this risk is not unique to this
	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
	skipping to change at page 43, line 7 ¶		skipping to change at page 42, 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-11 since draft-ietf-mile-rolie-09
			revision:
			Incorporated ART last call review and AD review changes
	Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08		Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08
	revision:		revision:
	TLS requirements changed to clarify TLS versioning and		TLS requirements changed to clarify TLS versioning and
	recommendations		recommendations
	Informative references and textual discussion added to Security		Informative references and textual discussion added to Security
	Considerations around HTTP Authentication and content Signing/		Considerations around HTTP Authentication and content Signing/
	Encryption.		Encryption.
End of changes. 36 change blocks.
	179 lines changed or deleted		120 lines changed or added
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/