draft-ietf-mile-rolie-05.txt   draft-ietf-mile-rolie-06.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft Pivotal Internet-Draft Pivotal
Intended status: Informational S. Banghart Intended status: Standards Track S. Banghart
Expires: May 4, 2017 D. Waltermire Expires: September 14, 2017 D. Waltermire
NIST NIST
October 31, 2016 March 13, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-05 draft-ietf-mile-rolie-06
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 security incidents, attack indicators, software representations of security incidents, attack indicators, software
vulnerabilities, configuration checklists, and other security vulnerabilities, configuration checklists, and other security
automation information as Web-addressable resources. Furthermore, automation information as Web-addressable resources. Furthermore,
consumers and other stakeholders may access and search this security consumers and other stakeholders may access and search this security
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 40 skipping to change at page 2, line 40
4.2. Knowledge Aggregation . . . . . . . . . . . . . . . . . . 6 4.2. Knowledge Aggregation . . . . . . . . . . . . . . . . . . 6
4.3. Resource-oriented Architecture . . . . . . . . . . . . . 6 4.3. Resource-oriented Architecture . . . . . . . . . . . . . 6
5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 7 5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 7
5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7 5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7
5.1.1. Use of the "app:workspace" Element . . . . . . . . . 8 5.1.1. Use of the "app:workspace" Element . . . . . . . . . 8
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 Discovery . . . . . . . . . . . . . . . . . . 9
5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 10 5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 10
5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 10
5.4. User Authentication and Authorization . . . . . . . . . . 11 5.4. User Authentication and Authorization . . . . . . . . . . 11
5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 11 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 12
5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 12
6. ROLIE Requirements for the Atom Syndication Format . . . . . 12 6. ROLIE Requirements for the Atom Syndication Format . . . . . 12
6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 12
6.1.1. Use of the "atom:category" Element . . . . . . . . . 13 6.1.1. Use of the "atom:category" Element . . . . . . . . . 13
6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 14
6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 15
6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 15 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 16
6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 16
6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 17
6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 17
6.2.4. Requirements for a Standalone Entry . . . . . . . . . 18 6.2.4. Use of the rolie:property Element . . . . . . . . . . 18
6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19
7. Available Extension Points Provided by ROLIE . . . . . . . . 18 7. Available Extension Points Provided by ROLIE . . . . . . . . 19
7.1. The Category Extension Point . . . . . . . . . . . . . . 18 7.1. The Category Extension Point . . . . . . . . . . . . . . 20
7.1.1. General Use of the "atom:category" Element . . . . . 19 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 . . . . . . . . . . . . . . . . . . . . . . . . 19 Types . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. The "rolie:format" Extension Point . . . . . . . . . . . 21 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22
7.3. The Link Relation Extension Point . . . . . . . . . . . . 21 7.3. The Link Relation Extension Point . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.4. The "rolie:property" Extension Point . . . . . . . . . . 23
8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 21 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 22 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23
8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 22 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 23
8.4. ROLIE Security Resource Information Type Sub-Registry . . 23 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.4. ROLIE Security Resource Information Type Sub-Registry . . 25
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . 26 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28 11.1. Normative References . . . . . . . . . . . . . . . . . . 28
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 29 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 30 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 31
B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 30 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 32
B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 33 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 32
B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 35 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 35
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 36 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 REST (Architectural S automation information sharing that follows the REST (Architectural S
tyles and the Design of Network-based Software Architectures) tyles and the Design of Network-based Software Architectures)
architectural style. In this approach, computer security resources architectural style. In this approach, computer security resources
are maintained in web-accessible repositories structured as Atom are maintained in web-accessible repositories structured as Atom
Syndication Format [RFC4287] Feeds. Representations of specific Syndication Format [RFC4287] Feeds. Representations of specific
types of security automation information are categorized and types of security automation information are categorized and
skipping to change at page 4, line 33 skipping to change at page 4, line 35
described by the IANA registry found in section 8.4. 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].
Definitions for some of the common computer security-related Definitions for some of the common computer security-related
terminology used in this document can be found in Section 2 of terminology used in this document can be found in Section 2 of
[RFC5070]. [RFC7970].
The following terms are unqiue to this specification: The following terms are unqiue to this specification:
Information Type A class of security automation information, having Information Type A class of security automation information, having
an associated data model, that is the subject of a security an associated data model, that is the subject of a security
process that can be automated. See section 7.1.2 for more process that can be automated. See section 7.1.2 for more
information. information.
Do we need other terms to be defined?
3. XML-related Conventions 3. XML-related Conventions
3.1. XML Namespaces 3.1. XML Namespaces
This specification uses XML Namespaces [W3C.REC-xml-names-20091208] This specification uses XML Namespaces [W3C.REC-xml-names-20091208]
to uniquely identify XML element names. It uses the following to uniquely identify XML element names. It uses the following
namespace prefix mappings for the indicated namespace URI: namespace prefix mappings for the indicated namespace URI:
"app" is used for the "http://www.w3.org/2007/app" namespace "app" is used for the "http://www.w3.org/2007/app" namespace
defined in [RFC5023]. defined in [RFC5023].
skipping to change at page 5, line 23 skipping to change at page 5, line 23
3.2. RELAX NG Compact Schema 3.2. RELAX NG Compact Schema
Some sections of this specification are illustrated with fragments of Some sections of this specification are illustrated with fragments of
a non-normative RELAX NG Compact schema [relax-NG]. However, the a non-normative RELAX NG Compact schema [relax-NG]. However, the
text of this specification provides the definition of conformance. text of this specification provides the definition of conformance.
Schema for the "http://www.w3.org/2007/app" and Schema for the "http://www.w3.org/2007/app" and
"http://www.w3.org/2005/Atom" namespaces appear in RFC5023 appendix B "http://www.w3.org/2005/Atom" namespaces appear in RFC5023 appendix B
[RFC5023] and RFC4287 appendix B [RFC4287] respectively. [RFC5023] and RFC4287 appendix B [RFC4287] respectively.
A complete RELAX NG Compact Schema for the new elements introduced by
ROLIE is provided in Appendix A.
4. Background and Motivation 4. Background and Motivation
Information sharing is one of the core components of automating Information sharing is one of the core components of automating
security processes. Vulnerabilities, configurations, software security processes. Vulnerabilities, configurations, software
identification, security incidents, and patching data are just a few identification, security incidents, and patching data are just a few
of the classes of information that are shared today to enable of the classes of information that are shared today to enable
effective security on a wide scale. However, as the scale of defense effective security on a wide scale. However, as the scale of defense
broadens to sometimes global networks, and the inherent scaling broadens to sometimes global networks, and the inherent scaling
issues of human-in-the-loop sharing become apparent, the need for issues of human-in-the-loop sharing become apparent, the need for
automation and machine-to-machine communication becomes apparent. automation and machine-to-machine communication becomes apparent.
skipping to change at page 10, line 5 skipping to change at page 10, line 9
5.1.3. Service Discovery 5.1.3. Service Discovery
This specification requires that an implementation MUST publish an This 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
sharing Collections that are provided by the repository. sharing Collections that are provided by the repository.
The Service Document SHOULD be discoverable via the organization's The Service Document SHOULD be discoverable via the organization's
Web home page or another well-known public resource. An example of Web home page or another well-known public resource. An example of
this can be found in appendix B.1. this can be found in appendix B.1.
The Service Document SHOULD be located at the standardized location The Service Document MUST be retrievable using the standardized URI
"https://{host:port}/rolie/servicedocument", where {host:port} is the template "https://{host:port}/rolie/servicedocument", where
authority portion of the URI. Dereferencing this URI MAY result in a {host:port} is the authority portion of the URI. Dereferencing this
redirect based on a HTTP 3xx status code to direct the client to the URI MAY result in a redirect based on an appropriate HTTP 3xx status
actual Service Document. This allows clients to have a well-known code to direct the client to the actual Service Document. This
location to find a ROLIE service document, while giving allows clients to have a well-known location to find a ROLIE service
implementations flexibility over how the service is deployed. document, while giving implementations flexibility over how the
service is deployed.
When deploying a Service Document for use by a closed consortium, the The service document MAY also be digitally signed and/or encrypted
service document MAY also be digitally signed and/or encrypted. For according to XML Signature Syntax and Processing [xmldsig] and XML
example, consider XML Signature Syntax and Processing [xmldsig] and Encryption Syntax and Processing [xmlenc] respectively.
XML Encryption Syntax and Processing. [xmlenc]
5.2. AtomPub Category Documents 5.2. AtomPub 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, and
Atom Syndication Feed and Entry documents provided by a publisher. A Atom Syndication Feed and Entry documents provided by a publisher. A
Category Document consists of one or more app:categories elements Category Document consists of one app:categories element that
that may each contain a number of app:collection elements. contains a number of inline atom:category elements, or a URI
referencing a Category Document that describes the repository.
A ROLIE implementation MUST publish an Category Document that A ROLIE implementation MUST publish an Category Document that
describes the set of atom:category elements and associated terms used describes the set of atom:category elements and associated terms used
within the implemented repository. within the implemented repository.
The Category Document MUST be retrievable using the standardized URI
template "https://{host:port}/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.
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 derived from [RFC7589].
The most recent published version of TLS MUST be supported, and any The most recent published version of TLS MUST be supported, and any
mandatory-to-implement (MTI) cipher suites in that version MUST be mandatory-to-implement (MTI) cipher suites in that version MUST be
supported as well. supported as well.
The server MUST support certificate-based client authentication. The The server MUST support certificate-based client authentication. The
skipping to change at page 12, line 13 skipping to change at page 12, line 28
POST to "/" MAY receive an HTTP status code 307 Temporary POST to "/" MAY receive an HTTP status code 307 Temporary
Redirect. In this case, the location header in the HTTP response Redirect. In this case, the location header in the HTTP response
will provide the URL of the appropriate RID endpoint, and the will provide the URL of the appropriate RID endpoint, and the
client may repeat the POST method at the indicated location. 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. MUST provide a 404 HTTP status code.
5.6. HTTP methods 5.6. HTTP methods
Servers MAY accept request methods beyond those specified in this
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
This section describes a number of restrictions of and extensions to This section describes a number of restrictions of and extensions to
the Atom Syndication Format [RFC4287] that define the use of that the Atom Syndication Format [RFC4287] that define the use of that
format in the context of a ROLIE-based solution. The normative format in the context of a ROLIE-based solution. The normative
requirements in this section are generally oriented towards content requirements in this section are generally oriented towards any
to be published to a ROLIE repository. An understanding of the Atom content to be published to a ROLIE repository. An understanding of
Syndication Format specification [RFC4287] is helpful to understand the Atom Syndication Format specification [RFC4287] is helpful to
the requirements in this section. understand the requirements in this section.
6.1. Use of the "atom:feed" element 6.1. Use of the "atom:feed" element
As described in RFC4287 section 4.1.1 [RFC4287], an Atom Feed is an As described in RFC4287 section 4.1.1 [RFC4287], an Atom Feed is an
XML-based document format that describes a list of related XML-based document format that describes a list of related
information items, also known as a Collection. Each Feed document, information items. The list of Atom Feeds provided by a ROLIE
represented using the atom:feed element, contains a collection of service instance are listed in the service's Service Document through
zero or more related information items individually called a "Member one or more app:collection elements. Each Feed document, represented
Entry" or "Entry". using the atom:feed element, contains a listing of zero or more
related information items individually called a "Member Entry" or
"Entry".
When applied to the problem domain of security automation information When applied to the problem domain of security automation information
sharing, an Atom Feed may be used to represent any meaningful sharing, an Atom Feed may be used to represent any meaningful
collection of security automation information resources. Each Entry collection of security automation information resources. Each Entry
in an atom:feed represents an individual resource (e.g., a specific in an atom:feed represents an individual resource (e.g., a specific
checklist , a software vulnerability record). Additional Feeds can checklist, a software vulnerability record). Additional Feeds can be
be used to represent other collections of security automation used to represent other collections of security automation resources.
resources.
The following Atom Feed definition represents a stricter definition The following Atom Feed definition represents a stricter definition
of the atom:feed element defined in RFC 4287 for use in a ROLIE Any of the atom:feed element defined in RFC 4287 for use in a ROLIE Any
element not specified here inherits its definition and requirements element not specified here inherits its definition and requirements
from [RFC4287]. from [RFC4287].
atomFeed = atomFeed =
element atom:feed { element atom:feed {
atomCommonAttributes, atomCommonAttributes,
(atomAuthor* (atomAuthor*
skipping to change at page 13, line 41 skipping to change at page 14, line 7
The following restrictions are imposed on the use of the The following restrictions are imposed on the use of the
atom:category element when used in an atom:feed: atom:category element when used in an atom:feed:
o An atom:feed element MUST minimally contain a single atom:category o An atom:feed element MUST minimally contain a single atom:category
element with the "scheme" attribute value of element with the "scheme" attribute value of
"urn:ietf:params:rolie:category:information-type". This category "urn:ietf:params:rolie:category:information-type". This category
MUST have an appropriate "term" attribute value as defined in MUST have an appropriate "term" attribute value as defined in
section 7.1.1. This ensures that a given Feed corresponds to a section 7.1.1. This ensures that a given Feed corresponds to a
specific type of security automation information. All member specific type of security automation information. All member
Entries in the Feed MUST represent security automation information Entries in the Feed MUST represent security automation information
records of this information type. records of the provided information type category or categories.
o Any atom:feed element that does not contain a child atom:category o Any atom:feed element that does not contain a child atom:category
element with the "scheme" attribute value of element with the "scheme" attribute value of
"urn:ietf:params:rolie:category:information-type" MUST NOT be "urn:ietf:params:rolie:category:information-type" MUST NOT be
considered a ROLIE Collection. This allows Feeds pertaining to considered a ROLIE Collection. This allows Feeds pertaining to
security automation information to co-exist alongside Feeds of security automation information to co-exist alongside Feeds of
other non-ROLIE information within the same AtomPub instance. other non-ROLIE information within the same AtomPub instance.
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 16, line 21 skipping to change at page 16, line 29
& atomContributor* & atomContributor*
& atomId & atomId
& atomLink* & atomLink*
& atomPublished? & atomPublished?
& atomRights? & atomRights?
& atomSource? & atomSource?
& atomSummary? & atomSummary?
& atomTitle & atomTitle
& atomUpdated & atomUpdated
& rolieFormat & rolieFormat
& rolieProperty
& extensionElement*) & extensionElement*)
} }
6.2.1. Use of the "atom:content" Element 6.2.1. Use of the "atom:content" Element
There MUST be exactly one atomContent element in the Entry. The There MUST be exactly one atomContent 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 =
skipping to change at page 17, line 37 skipping to change at page 17, line 46
express the information referenced in the atom:content element of an express the information referenced in the atom:content element of an
atom:entry. It also allows a schema to be identified that can be atom:entry. It also allows a schema to be identified that can be
used when parsing the content to verify or better understand the used when parsing the content to verify or better understand the
structure of the content. structure of the content.
There MUST be exactly one rolie:format element in an atom:entry. The There MUST be exactly one rolie:format element in an atom:entry. The
element MUST adhere to this definition: element MUST adhere to this definition:
rolieFormat = rolieFormat =
element rolie:format { element rolie:format {
atomCommonAttributes, appCommonAttributes,
attribute ns { atomURI }, attribute ns { atomURI },
attribute version { text } ?, attribute version { text } ?,
attribute schema-location { atomURI } ?, attribute schema-location { atomURI } ?,
attribute schema-type { atomMediaType } ?, attribute schema-type { atomMediaType } ?,
empty empty
} }
The rolie:format element MUST provide a "ns" attribute that The rolie:format element MUST provide a "ns" attribute that
identifies the data model of the resource referenced by the identifies the data model of the resource referenced by the
atom:content element. For example, the namespace used may be an XML atom:content element. For example, the namespace used may be an XML
skipping to change at page 18, line 17 skipping to change at page 18, line 25
atom:content. atom:content.
The rolie:format element MAY provide a "schema-location" element that The rolie:format element MAY provide a "schema-location" element that
is a URI that identifies a schema resource that can be used to is a URI that identifies a schema resource that can be used to
validate the related atom:content. validate the related atom:content.
The rolie:format element MAY provide a "schema-type" element, which The rolie:format element MAY provide a "schema-type" element, which
is a mime type identifying the format of the schema resource is a mime type identifying the format of the schema resource
identified by the "schema-location" attribute. identified by the "schema-location" attribute.
6.2.4. Requirements for a Standalone Entry For example, the nominal element <rolie:format
ns="urn:ietf:params:xml:ns:iodef-2.0" version="2.0" schema-
location="https://www.iana.org/assignments/xml-registry/schema/iodef-
2.0.xsd"/> would provide an indication that the content of this entry
is using the IODEF v2 format.
6.2.4. Use of the rolie:property Element
An atom:category element provides a way to associate a name/value
pair of categorical information using the scheme and term attributes
to represent the name, and the label attribute to represent the
value. When used in this way an atom:category allows a specific
label to be selected from a finite set of possible label values that
can be used to further classify a given atom:entry or atom:feed.
Within ROLIE, there may be a need to associate additional metadata
with an atom:entry. In such a case, use of an atom:category is not
practical to represent name/value data for which the allowed values
are unbounded. Instead, ROLIE has introduced a new rolie:property
element that can represent non-categorical metadata as name/value
pairs. Examples include content-specific identifiers, naming data,
and other properties that allow for unbounded values.
There MAY be zero or more rolie:property elements in an atom:entry.
The element MUST adhere to this definition:
rolieProperty =
element rolie:property {
app:appCommonAttributes,
attribute name { atom:atomURI },
attribute value { text }
empty
}
The name attribute provides a URI that identifies the namespace and
name of the property as a URI.
The value attribute is text that provides a value for the property
identified by the name attribute.
For example, the nominal element <rolie:property
name="urn:ietf:params:rolie:property:csirt-iodef-id" value="12345"/>
would expose an IODEF ID value contained in a given entry's content.
The name used in the example also demonstrates the use of a
registered ROLIE property extension, which is described in
Section 7.4.
Implementations MAY use locally defined and namespaced elements in an
Entry in order to provide additional information. Clients that do
not recognize a property with an unregistered name attribute MAY
ignore the rolie:property.
6.2.5. Requirements for a Standalone Entry
If an Entry is ever shared as a standalone resource, separate from If an Entry is ever shared as a standalone resource, separate from
its containing Feed, then the following additional requirements its containing Feed, then the following additional requirements
apply: apply:
o The Entry MUST have a atom:link element with rel="collection" and o The Entry MUST have a atom:link element with rel="collection" and
href="[IRI of the containing Collection]". This allows the Feed href="[IRI of the containing Collection]". This allows the Feed
or Feeds for which the Entry is a member to be discovered, along or Feeds for which the Entry is a member to be discovered, along
with the related information the Feed may contain. In the case of with the related information the Feed may contain. In the case of
the Entry have multiple containing Feeds, the Entry MUST have one the Entry have multiple containing Feeds, the Entry MUST have one
skipping to change at page 19, line 36 skipping to change at page 20, line 49
value, and a "scheme" attribute that provides an identifier for the value, and a "scheme" attribute that provides an identifier for the
category type. The "scheme" provides a means to describe how a set category type. The "scheme" provides a means to describe how a set
of category terms should be used and provides a namespace that can be of category terms should be used and provides a namespace that can be
used to differentiate terms provided by multiple organizations with used to differentiate terms provided by multiple organizations with
different semantic meaning. different semantic meaning.
To further differentiate category types used in ROLIE, an IANA sub- To further differentiate category types used in ROLIE, an IANA sub-
registry has been established for ROLIE protocol parameters to registry has been established for ROLIE protocol parameters to
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. discussed in section 8.3 using the name field with a type parameter
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) [RFC2141] 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
skipping to change at page 20, line 10 skipping to change at page 21, line 26
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
2. identify that an "atom:feed" element in an Atom Feed contains 2. identify that an "atom:feed" element in an Atom Feed contains
Entries pertaining to a specific type of security automation Entries pertaining to a specific type of security automation
information (see section 6.1.1). information (see section 6.1.1).
3. identify the information type of a standalone Resource (see 3. identify the information type of a standalone Resource (see
section 6.2.4). section 6.2.5).
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]. Notional examples of information types include:
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 malicious activity; and associated meta-data" (from [RFC7970]).
[I-D.ietf-mile-rfc5070-bis]).
incident: Information pertaining to and "derived analysis from incident: Information pertaining to and "derived analysis from
security incidents" (from [I-D.ietf-mile-rfc5070-bis]). 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.
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.
skipping to change at page 21, line 34 skipping to change at page 23, line 5
7.3. The Link Relation Extension Point 7.3. The Link Relation Extension Point
This document uses several link relations defined in the IANA Link This document uses several link relations defined in the IANA Link
Relation Types registry [2]. Additional link relations can be Relation Types registry [2]. Additional link relations can be
registered in this registry to allow new relationships to be registered in this registry to allow new relationships to be
represented in ROLIE according to RFC 4287 section 4.2.7.2 [RFC4287]. represented in ROLIE according to RFC 4287 section 4.2.7.2 [RFC4287].
Based on the preceding reference, if the link relation is too Based on the preceding reference, if the link relation is too
specific or limited in the intended use, an absolute IRI can be used specific or limited in the intended use, an absolute IRI can be used
in lieu of registering a new simple name with IANA. in lieu of registering a new simple name with IANA.
7.4. The "rolie:property" Extension Point
As discussed previously in Section 6.2.4, many formats contain unique
identifying and characterizing properties that are vital for sharing
information. In order to provide a global reference for these
properties, this document establishes an IANA registry in Section 7.4
that allows ROLIE extensions to register named properties using the
name field with a type parameter of "property" to indicate a property
extension. Implementations SHOULD prefer the use of registered
properties over implementation specific properties when possible.
ROLIE extensions are expected to register new and use existing
properties to provide valuable identifying and characterizing
information for a given information type and/or format.
8. IANA Considerations 8. IANA Considerations
This document has a number of IANA considerations described in the This document has a number of IANA considerations described in the
following subsections. following subsections.
8.1. XML Namespaces and Schema URNs 8.1. XML Namespaces and Schema URNs
This document uses URNs to describe XML namespaces and XML schemas This document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in [RFC3688]. conforming to a registry mechanism described in [RFC3688].
skipping to change at page 22, line 51 skipping to change at page 24, line 37
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 [RFC5226]. 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.
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 value is "category". {type}: The parameter type. The allowed values are "category"
"category" denotes a category extension as discussed in or "property". "category" denotes a category extension as
Section 7.1. While a single value is used in this discussed in Section 7.1. "property" denotes a property
specification, future revisions or extensions of this extension as discussed in Section 7.4.
specification may define additional {type} values.
{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 [RFC2141]). This string must be
unique within the namespace defined by the {type} keyword. unique within the namespace defined by the {type} keyword.
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
skipping to change at page 27, line 17 skipping to change at page 28, line 49
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[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>. <http://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, <http://www.rfc-editor.org/info/rfc5023>.
[RFC5070] Danyliw, R., Meijer, J., and Y. Demchenko, "The Incident [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Object Description Exchange Format", RFC 5070, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
DOI 10.17487/RFC5070, December 2007, November 2016, <http://www.rfc-editor.org/info/rfc7970>.
<http://www.rfc-editor.org/info/rfc5070>.
[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>. <http://www.rfc-editor.org/info/rfc6546>.
[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, <http://www.rfc-editor.org/info/rfc3553>.
skipping to change at page 28, line 21 skipping to change at page 30, line 5
[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, <http://www.rfc-editor.org/info/rfc4642>.
[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/compact-
20021121.html>. 20021121.html>.
11.2. Informative References
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[SAML-core] [SAML-core]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core- Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005, <http://docs.oasis- 2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-core-2.0-os.pdf>. open.org/security/saml/v2.0/saml-core-2.0-os.pdf>.
[SAML-prof] [SAML-prof]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS P., Philpott, R., and E. Maler, "Profiles for the OASIS
skipping to change at page 28, line 43 skipping to change at page 30, line 42
<http://docs.oasis-open.org/security/saml/v2.0/ <http://docs.oasis-open.org/security/saml/v2.0/
saml-profiles-2.0-os.pdf>. saml-profiles-2.0-os.pdf>.
[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>.
11.2. Informative References
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>.
[I-D.ietf-mile-rfc5070-bis]
Danyliw, R., "The Incident Object Description Exchange
Format v2", draft-ietf-mile-rfc5070-bis-26 (work in
progress), October 2016.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
[xmldsig] Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and E. [xmldsig] Bartel, M., Boyer, J., Fox, B., LaMacchia, B., and E.
Simon, "XML Signature Syntax and Processing (Second Simon, "XML Signature Syntax and Processing (Second
Edition)", June 2008, <https://www.w3.org/TR/xmldsig- Edition)", June 2008, <https://www.w3.org/TR/xmldsig-
core/>. core/>.
[xmlenc] Imamura, T., Dillaway, B., and E. Simon, "XML Encryption [xmlenc] Imamura, T., Dillaway, B., and E. Simon, "XML Encryption
Syntax and Processing", December 2002, Syntax and Processing", December 2002,
<https://www.w3.org/TR/xmlenc-core/>. <https://www.w3.org/TR/xmlenc-core/>.
[XACML] Rissanen, E., "eXtensible Access Control Markup Language [XACML] Rissanen, E., "eXtensible Access Control Markup Language
skipping to change at page 30, line 6 skipping to change at page 32, line 6
[3] http://csrc.nist.gov/groups/SNS/rbac/ [3] 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:format element # RELAX NG Compact Syntax Grammar for the rolie ns
namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0" namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0"
namespace atom = "http://www.w3.org/2005/Atom" namespace atom = "http://www.w3.org/2005/Atom"
namespace app = "http://www.w3.org/2007/app"
# rolie:format # rolie:format
rolieFormat = rolieFormat =
element rolie:format { element rolie:format {
atom:atomCommonAttributes, app:appCommonAttributes,
attribute ns { atom:atomURI }, attribute ns { atom:atomURI },
attribute version { text } ?, attribute version { text } ?,
attribute schema-location { atom:atomURI } ?, attribute schema-location { atom:atomURI } ?,
attribute schema-type { atom:atomMediaType } ?, attribute schema-type { atom:atomMediaType } ?,
empty empty
} }
# rolie:property
rolieProperty =
element rolie:property {
app:appCommonAttributes,
attribute name { atom:atomURI },
attribute value { text }
empty
}
Appendix B. Examples of Use Appendix B. Examples of Use
B.1. Service Discovery B.1. Service Discovery
This section provides a non-normative example of a client doing This section provides a non-normative example of a client doing
service discovery. service discovery.
An Atom service document enables a client to dynamically discover An Atom Service Document enables a client to dynamically discover
what Feeds a particular publisher makes available. Thus, a provider what Feeds a particular publisher makes available. Thus, a provider
uses an Atom service document to enable clients or other authorized uses an Atom Service Document to enable authorized clients to
parties to determine what specific information the provider makes determine what specific information the provider makes available to
available to the community. While the service document is at a the community. While the Service Document is accessible at a pre-
required location, the service document could also be made available determined location, the Service Document can also be made accessible
at any well known location, such as via a link from the producer's from any well known location, such as via a link from the producer's
home page. home page.
A client may format an HTTP GET request to retrieve the service A client may format an HTTP GET request to retrieve the service
document from the specified location: document from the specified location:
GET /rolie/servicedocument GET /rolie/servicedocument
Host: www.example.org Host: www.example.org
Accept: application/atomsvc+xml Accept: application/atomsvc+xml
Notice the use of the HTTP Accept: request header, indicating the Notice the use of the HTTP Accept: request header, indicating the
MIME type for Atom service discovery. The response to this GET MIME type for Atom service discovery. The response to this GET
request will be an XML document that contains information on the request will be an XML document that contains information on the
specific Feed Collections that are provided by the provider. specific Collections that are provided.
Example HTTP GET response: Example HTTP GET response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:09:11 GMT Date: Fri, 24 Aug 2016 17:09:11 GMT
Content-Length: 570 Content-Length: 570
Content-Type: application/atomsvc+xml;charset="utf-8" Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<service xmlns="http://www.w3.org/2007/app" <service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom"> xmlns:atom="http://www.w3.org/2005/Atom">
<workspace> <workspace>
<atom:title type="text">Vulnerabilities</atom:title> <atom:title type="text">Vulnerabilities</atom:title>
<collection href="http://example.org/provider/vulns"> <collection href="http://example.org/provider/vulns">
<atom:title type="text">Vulnerabilities Feed</atom:title> <atom:title type="text">Vulnerabilities Feed</atom:title>
<categories fixed="yes"> <categories fixed="yes">
<atom:category <atom:category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/> term="vulnerability"/>
</categories> </categories>
</collection> </collection>
</workspace> </workspace>
</service> </service>
This simple Service Document example shows that this server provides This simple Service Document example shows that the server provides
one workspace, named "Vunerabilities". Within that workspace, the one workspace, named "Vunerabilities". Within that workspace, the
producer makes one Feed Collection available. server makes one Collection available.
A server may also offer a number of different Feeds, each containing A server may also offer a number of different Collections, each
different types of security automation information. In the following containing different types of security automation information. In
example, the Feeds have been categorized. This categorization will the following example, a number of different Collections are
help the clients to decide which Feeds will meet their needs. provided, each with its own category and authorization scope. This
categorization will help the clients to decide which Collections will
meet their needs.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:10:11 GMT Date: Fri, 24 Aug 2016 17:10:11 GMT
Content-Length: 1912 Content-Length: 1912
Content-Type: application/atomsvc+xml;charset="utf-8" Content-Type: application/atomsvc+xml;charset="utf-8"
<?xml version="1.0" encoding='utf-8'?> <?xml version="1.0" encoding='utf-8'?>
<service xmlns="http://www.w3.org/2007/app" <service xmlns="http://www.w3.org/2007/app"
xmlns:atom="http://www.w3.org/2005/Atom"> xmlns:atom="http://www.w3.org/2005/Atom">
<workspace> <workspace>
<atom:title>Public Security Information Sharing</atom:title> <atom:title>Public Security Information Sharing</atom:title>
<collection <collection
href="http://example.org/provider/public/vulns"> href="http://example.org/provider/public/vulns">
<atom:title>Public Vulnerabilities</atom:title> <atom:title>Public Vulnerabilities</atom:title>
<link rel="service" <atom:link rel="service"
href="www.example.com/rolie/servicedocument"> href="www.example.com/rolie/servicedocument">
<categories fixed="yes"> <categories fixed="yes">
<atom:category <atom:category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/> term="vulnerability"/>
</categories> </categories>
</collection> </collection>
</workspace> </workspace>
<workspace> <workspace>
<atom:title>Private Consortium Sharing</atom:title> <atom:title>Private Consortium Sharing</atom:title>
<collection <collection
href="http://example.org/provider/private/vulns"> href="http://example.org/provider/private/incidents">
<atom:title>Incidents</atom:title> <atom:title>Incidents</atom:title>
<link rel="service" <atom:link rel="service"
href="www.example.com/rolie/servicedocument"> href="www.example.com/rolie/servicedocument">
<categories fixed="yes"> <categories fixed="yes">
<atom:category <atom:category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="incidents"/> term="incident"/>
</categories> </categories>
</collection> </collection>
</workspace> </workspace>
</service> </service>
In this example, the provider is making available a total of two Feed In this example, the provider is making available a total of two
Collections, organized into two different workspaces. The first Collections, organized into two different workspaces. The first
workspace contains a Feed consisting of publicly available software workspace contains a Collection consisting of publicly available
vulnerabilities. The second workspace provides one additional software vulnerabilities. The second workspace provides an incident
vulnerability Feed, for use by a private sharing consortium. An Collection for use by a private sharing consortium. An appropriately
appropriately authenticated and authorized client may then proceed to authenticated and authorized client may then proceed to make HTTP
make GET requests for one or more of these Feeds. The publicly requests for these Collections. The publicly provided vulnerability
provided incident information may be accessible with or without information may be accessible with or without authentication.
authentication. However, users accessing the Feed targeted to the However, users accessing the Collection restricted to authorized
private sharing consortium would be expected to authenticate, and members of a private sharing consortium are expected to authenticate
appropriate authorization policies would subsequently be enforced by before access is allowed.
the Feed provider.
B.2. Feed Retrieval B.2. Feed Retrieval
This section provides a non-normative example of a client retrieving This section provides a non-normative example of a client retrieving
an incident Feed. an vulnerability Feed.
Having discovered the available security information sharing Feeds, a Having discovered the available security information sharing
client who is a member of the general public may be interested in Collections, a client who is a member of the general public may be
receiving the Feed of public vulnerabilities. The client may interested in receiving the Collection of public vulnerabilities.
retrieve this Feed by performing an HTTP GET operation on the The client may retrieve the Feed for this Collection by performing an
indicated URL. HTTP GET operation on the URL indicated by the Collection's "href"
attribute.
Example HTTP GET request for a Feed: Example HTTP GET request for a Feed:
GET /provider/vulns GET /provider/public/vulns
Host: www.example.org Host: www.example.org
Accept: application/atom+xml Accept: application/atom+xml
The corresponding HTTP response would be an XML document containing The corresponding HTTP response would be an XML document containing
the incidents Feed: the vulnerability Feed:
Example HTTP GET response for a Feed: Example HTTP GET response for a Feed:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:20:11 GMT Date: Fri, 24 Aug 2016 17:20:11 GMT
Content-Length: 2882 Content-Length: 2882
Content-Type: application/atom+xml;type=feed;charset="utf-8" Content-Type: application/atom+xml;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" <feed xmlns="http://www.w3.org/2005/Atom"
xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
xml:lang="en-US"> xml:lang="en-US">
<id>http://www.example.org/provider/vulns</id> <id>2a7e265a-39bc-43f2-b711-b8fd9264b5c9</id>
<title type="text"> <title type="text">
Atom formatted representation of Atom formatted representation of
a feed of XML incident documents a feed of XML vulnerability documents
</title> </title>
<atom:category <category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="vulnerability"/> term="vulnerability"/>
<updated>2012-05-04T18:13:51.0Z</updated> <updated>2016-05-04T18:13:51.0Z</updated>
<link rel="self" href="http://example.org/provider/vulns" /> <link rel="self"
href="http://example.org/provider/public/vulns" />
<link rel="service" <link rel="service"
href="http://example.org/rolie/servicedocument"/> href="http://example.org/rolie/servicedocument"/>
<entry> <entry>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/> <rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<id> <id>dd786dba-88e6-440b-9158-b8fae67ef67c</id>
http://www.example.org/provider/vulns/123456 <title>Sample Vulnerability</title>
</id> <published>2015-08-04T18:13:51.0Z</published>
<title>Sample Incident</title> <updated>2015-08-05T18:13:51.0Z</updated>
<published>2014-08-04T18:13:51.0Z</published> <summary>A vulnerability issue identified by CVE-...</summary>
<updated>2014-08-05T18:13:51.0Z</updated>
<summary>A short description of this resource</summary>
<content type="application/xml" <content type="application/xml"
src="http://www.example.org/provider/vulns/123456/data" src="http://www.example.org/provider/vulns/123456/data"
</entry> </entry>
<entry> <entry>
<!-- ...another entry... --> <!-- ...another entry... -->
</entry> </entry>
</feed> </feed>
This Feed document has two atom entries, one of which has been This Feed document has two Atom Entries, one of which has been
elided. The completed Entry illustrates an Atom <entry> element that elided. The first Entry illustrates an atom:entry element that
provides a summary of essential details about one particular provides a summary of essential details about one particular
incident. Based upon this summary information and the provided vulnerability. Based upon this summary information and the provided
category information, a client may choose to do an HTTP GET operation category information, a client may choose to do an HTTP GET request,
to retrieve the full details of the incident. This example on the content "src" attribute, to retrieve the full details of the
exemplifies the benefits a RESTful alternative has to traditional vulnerability.
point-to-point messaging systems.
B.3. Entry Retrieval B.3. Entry Retrieval
This section provides a non-normative example of a client retrieving This section provides a non-normative example of a client retrieving
an incident as an Atom Entry. an vulnerability as an Atom Entry.
Having retrieved the Feed of interest, the client may then decide Having retrieved the Feed of interest, the client may then decide,
based on the description and/or category information that one of the based on the description and/or category information, that one of the
entries in the Feed is of further interest. The client may retrieve entries in the Feed is of further interest. The client may retrieve
this incident Entry by performing an HTTP GET operation on the this vulnerability Entry by performing an HTTP GET operation on the
indicated URL. URL indicated by the "src" attribute of the atom:content element.
Example HTTP GET request for an Entry: Example HTTP GET request for an Entry:
GET /provider/vulns/123456 GET /provider/public/vulns/123456
Host: www.example.org Host: www.example.org
Accept: application/atom+xml Accept: application/atom+xml;type=entry
The corresponding HTTP response would be an XML document containing The corresponding HTTP response would be an XML document containing
the incident: the Atom Entry for the vulnerability record:
Example HTTP GET response for an Entry: Example HTTP GET response for an Entry:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Fri, 24 Aug 2012 17:30:11 GMT Date: Fri, 24 Aug 2016 17:30:11 GMT
Content-Length: 4965 Content-Length: 713
Content-Type: application/atom+xml;type=entry;charset="utf-8" Content-Type: application/atom+xml;type=entry;charset="utf-8"
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<entry> <entry xmlns="http://www.w3.org/2005/Atom"
<id>http://www.example.org/provider/vulns/123456</id> xmlns:rolie="urn:ietf:params:xml:ns:rolie-1.0"
<title>Sample Incident</title> xml:lang="en-US">
<published>2012-08-04T18:13:51.0Z</published> <id>f63aafa9-4082-48a3-9ce6-97a2d69d4a9b</id>
<updated>2012-08-05T18:13:51.0Z</updated> <title>Sample Vulnerability</title>
<atom:category <published>2015-08-04T18:13:51.0Z</published>
<updated>2015-08-05T18:13:51.0Z</updated>
<category
scheme="urn:ietf:params:rolie:category:information-type" scheme="urn:ietf:params:rolie:category:information-type"
term="incident"/> term="vulnerability"/>
<summary>A short description of this incident resource</summary> <summary>A vulnerability issue identified by CVE-...</summary>
<rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/> <rolie:format ns="urn:ietf:params:xml:ns:exampleformat"/>
<content type="application/xml" <content type="application/xml"
src="http://www.example.org/provider/vulns/123456/data"> src="http://www.example.org/provider/vulns/123456/data">
</content> </content>
</entry> </entry>
As can be seen in the example response, above, an XML document is The example response above shows an XML document referenced by the
linked to in the attributes of the Atom <content> element. The "src" attribute of the atom:content element. The client may retrieve
client may now process the XML document as needed. the document using this URL.
Note also that, as described previously, the content of the Atom Appendix C. Change History
<category> element is application-defined. The Atom categories have
been assigned based on the IANA table content model.
Finally, it should be noted that in order to optimize the client Changes in draft-ietf-mile-rolie-06 since draft-ietf-mile-rolie-05
experience, and avoid an additional round trip, a Feed provider may version, November 2, 2016 to TODO, 2016
choose to include certain Entry elements inline, as part of the Feed
document. That is, an Atom <entry> element within a Feed document
may contain arbitrary non-required Atom elements as children. In
this case, the client will receive the more explicit information on
entries from within the Feed. The decision of whether to include
extra Entry elements inline or to include it as a link is a design
choice left to the Feed provider (e.g. based upon local environmental
factors such as the number of entries contained in a Feed, the
available network bandwidth, the available server compute cycles, the
expected client usage patterns, etc.).
Appendix C. Change History Changed to standards track
Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-04 Added the rolie:property element
Fixed references (Normative vs Informative)
Set Service and Category document URL template requirements
Fixed XML snippets in examples
Changes in draft-ietf-mile-rolie-05 since draft-ietf-mile-rolie-04
version, October 21, 2016 to November 2, 2016
Added ROLIE specific terminology to section 2
Added AtomPub Category Document in section 5.2
Edited document, improving consistency in terminology usage and
capitalization of key terms, as well as enhancing clarity.
Removed unused format parameter type in section 8.3
Schema removed, the normative schema consists of the snippets in
the requirements sections.
Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-03
version, July 8, 2016 to October 31, 2016 version, July 8, 2016 to October 31, 2016
o Further specification and clarification of requirements o Further specification and clarification of requirements
o IANA Considerations and extension system fleshed out and o IANA Considerations and extension system fleshed out and
described. described.
o Examples and References updated. o Examples and References updated.
o Schema created. o Schema created.
skipping to change at page 37, line 11 skipping to change at page 39, line 23
o Established rough version of IANA table extension system along o Established rough version of IANA table extension system along
with explanations of said system. with explanations of said system.
o Re-organized document to put non-vital information in appendices. o Re-organized document to put non-vital information in appendices.
Changes made in draft-ietf-mile-rolie-02 since draft-field-mile- Changes made in draft-ietf-mile-rolie-02 since draft-field-mile-
rolie-01 version, December, 2015 to May 27, 2016: rolie-01 version, December, 2015 to May 27, 2016:
o All CSIRT and IODEF/RID material moved to companion CSIRT document o All CSIRT and IODEF/RID material moved to companion CSIRT document
TODO: add reference
o Recast document into a more general use perspective. The o Recast document into a more general use perspective. The
implication of CSIRTs as the defacto end-user has been removed implication of CSIRTs as the defacto end-user has been removed
where ever possible. All of the original CSIRT based use cases where ever possible. All of the original CSIRT based use cases
remain completely supported by this document, it has been opened remain completely supported by this document, it has been opened
up to support many other use cases. up to support many other use cases.
o Changed the content model to broaden support of representation o Changed the content model to broaden support of representation
o Edited and rewrote much of sections 1,2 and 3 in order to o Edited and rewrote much of sections 1,2 and 3 in order to
 End of changes. 81 change blocks. 
200 lines changed or deleted 301 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/