draft-ietf-mile-rolie-07.txt   draft-ietf-mile-rolie-08.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: November 25, 2017 D. Waltermire Expires: January 18, 2018 D. Waltermire
NIST NIST
May 24, 2017 July 17, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-07 draft-ietf-mile-rolie-08
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 25, 2017. This Internet-Draft will expire on January 18, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
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 Discovery . . . . . . . . . . . . . . . . . . 9
5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9 5.2. AtomPub Category Documents . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . 11
5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . 15
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. Use of the rolie:property Element . . . . . . . . . . 18 6.2.4. Use of the rolie:property Element . . . . . . . . . . 18
6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 19
7. Available Extension Points Provided by ROLIE . . . . . . . . 19 7. Available Extension Points Provided by ROLIE . . . . . . . . 20
7.1. The Category Extension Point . . . . . . . . . . . . . . 20 7.1. The Category Extension Point . . . . . . . . . . . . . . 20
7.1.1. General Use of the "atom:category" Element . . . . . 20 7.1.1. General Use of the "atom:category" Element . . . . . 21
7.1.2. Identification of Security Automation Information 7.1.2. Identification of Security Automation Information
Types . . . . . . . . . . . . . . . . . . . . . . . . 21 Types . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 22
7.3. The Link Relation Extension Point . . . . . . . . . . . . 22 7.3. The Link Relation Extension Point . . . . . . . . . . . . 23
7.4. The "rolie:property" Extension Point . . . . . . . . . . 23 7.4. The "rolie:property" Extension Point . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 24
8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 24 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 25
8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 25
8.4. ROLIE Security Resource Information Type Sub-Registry . . 26 8.4. ROLIE Security Resource Information Type Sub-Registry . . 28
8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 27 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 32 12.2. Informative References . . . . . . . . . . . . . . . . . 33
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 33 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35
Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 34 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36
B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 34 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36
B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 37 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39
B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 39 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41
Appendix C. Change History . . . . . . . . . . . . . . . . . . . 40 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44
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 7, line 45 skipping to change at page 7, line 45
| o- ... | o- ...
| |
o- ... o- ...
5.1.1. Use of the "app:workspace" Element 5.1.1. Use of the "app:workspace" Element
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 impose any information resources. This specification does not restrict the
restrictions on the number of Workspaces that may be in a Service number of Workspaces that may be in a Service Document or the
Document or the specific Collections to be provided within a given specific Collections to be provided within a given Workspace.
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 RECOMMENDED that
implementations segregate public and private Collections into implementations segregate public and private Collections into
different app:workspace elements. By doing this, Workspaces that different app:workspace elements. By doing this, Workspaces that
contain private information can be ignored by clients or can be contain private information can be ignored by clients or can be
omitted from the Service Document provided to a client that lacks the omitted from the Service Document provided to a client that lacks the
appropriate privilege to access the set of Collections associated appropriate privilege to access the set of Collections associated
with the Workspace. with the Workspace.
skipping to change at page 8, line 25 skipping to change at page 8, line 24
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
information resources pertaining to a given type of security information resources pertaining to a given type of security
automation information. Collections are represented as Atom Feeds as automation information. Collections are represented as Atom Feeds as
per RFC 5023. Atom Feed specific requirements are defined in section per RFC 5023. Atom Feed specific requirements are defined in section
6.1. 6.1.
The following restrictions are imposed on the use of the ROLIE defines specialized data requirements for Collections, Feeds,
app:collection element for ROLIE implementations: and Entries containing security automation related data. The
difference between a ROLIE and a non-ROLIE Collection defined in a
o The atom:category elements contained in the app:categories element Service Document can be determined as follows:
MUST be the same set of atom:categories used in the Atom Feed
resource indicated by the app:collection "href" attribute value.
This ensures that the category metadata associated with the
Collection is discoverable in both the Feed and the corresponding
Collection in the Service Document.
o An app:collection pertaining to a security automation information ROLIE Collection: For an app:collection to be considered a ROLIE
resource Feed MUST contain an app:categories element that Collection, the app:collection MUST contain an app:categories
minimally contains a single atom:category element with the element that contains only one atom:category element with the
"scheme" attribute value of "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 Collection corresponds section 7.1.1. This ensures that a given Collection corresponds
to a specific type of security automation information. to a specific type of security automation information.
o Any app:collection element that does not contain a descendant Non-ROLIE Collection: For an app:collection to be considered a non-
atom:category element with the "scheme" attribute value of ROLIE Collection, the app:collection MUST NOT contain an
"urn:ietf:params:rolie:category:information-type" MUST be atom:category element with a "scheme" attribute value of
considered a non-ROLIE Collection. This allows Collections "urn:ietf:params:rolie:category:information-type".
pertaining to security automation information to co-exist
alongside Collections of other non-ROLIE information within the By distinguishing between ROLIE and non-ROLIE Collections in this
same AtomPub instance. way, implementations supporting ROLIE can host Collections pertaining
to security automation information alongside Collections of other
non-ROLIE information within the same AtomPub instance.
The following are additional requirements on the use of the
app:collection element for a ROLIE Collection:
o The child atom:category elements contained in the app:categories
element MUST be the same set of atom:category elements used in the
Atom Feed resource referenced by the app:collection "href"
attribute value. This ensures that the category metadata
associated with the Collection and the associated Feed is
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 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
skipping to change at page 10, line 19 skipping to change at page 10, line 26
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. An
implementation MAY use any TLS cipher suite that supports mutual implementation MUST support the set of TLS cipher suites that are
authentication. 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 During the TLS negotiation, the client MUST carefully examine the
certificate presented by the server to determine if it meets the certificate presented by the server to determine if it meets the
client's expectations. Particularly, the client MUST check its client's expectations. Particularly, the client MUST check its
understanding of the server hostname against the server's identity as understanding of the server hostname against the server's identity as
presented in the server Certificate message, in order to prevent man- presented in the server Certificate message, in order to prevent man-
in-the-middle attacks. Matching is performed according to the rules in-the-middle attacks. Matching is performed according to the rules
laid out in the Security Considerations section of [RFC4642]. laid out in the Security Considerations section of [RFC4642]. If the
match fails, the client MUST either ask for explicit user
If the match fails, the client MUST either ask for explicit user
confirmation or terminate the connection and indicate the server's confirmation or terminate the connection and indicate the server's
identity is suspect. Additionally, clients MUST verify the binding identity is suspect. If the client has external information as to
between the identity of the servers to which they connect and the the expected identity of the server, the hostname check MAY be
public keys presented by those servers. Client implementations omitted.
SHOULD support an equivalent certificate validation approach to the
what is defined in Section 6 of [RFC5280], but MAY supplement that Clients MUST verify the binding between the identity of the servers
algorithm with other validation methods that achieve equivalent to which they connect and the public keys presented by those servers.
levels of verification (such as comparing the server certificate Client implementations SHOULD support a certificate validation
against a local store of already-verified certificates and identity approach based on section 6 of [RFC5280].
bindings). If the client has external information as to the expected
identity of the server, the hostname check MAY be omitted.
The server MUST be capable of verifying the identity of the client The server MUST be capable of verifying the identity of the client
with certificate-based authentication according to local policy to with certificate-based authentication according to local policy to
ensure that the incoming client request is legitimate before any ensure that the incoming client request is legitimate before any
configuration or state data is sent to or received from the client. configuration or state data is sent to or received from the client.
5.4. User Authentication and Authorization 5.4. User Authentication and Authorization
Implementations MUST support user authentication. However, a given Implementations MUST support user authentication. However, a given
implementation MAY allow user authentication to be disabled on a feed implementation MAY allow user authentication to be disabled on a feed
skipping to change at page 11, line 24 skipping to change at page 11, line 26
(e.g., SAML 2.0). (e.g., SAML 2.0).
This document does not mandate the use of any specific user This document does not mandate the use of any specific user
authorization mechanisms. However, service implementers SHOULD authorization mechanisms. However, service implementers SHOULD
provide appropriate authorization checking for all resource accesses, provide appropriate authorization checking for all resource accesses,
including individual Atom Entries, Atom Feeds, and Atom Service including individual Atom Entries, Atom Feeds, and Atom Service
Documents. Documents.
5.5. / (forward slash) Resource URL 5.5. / (forward slash) Resource URL
The "/" resource MAY be provided 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]. If the "/" resource Defense (RID) Messages over HTTP/TLS [RFC6546].
is supported the following behavior MUST be also supported:
o Consistent with RFC6546 errata, a client requesting a GET on "/" The following additional requirements apply for implementations
SHOULD receive an HTTP status code 405 Method Not Allowed. supporting handling of the "/" resource::
o Consistent with RFC6546 errata, a client requesting a GET on the
"/" resource SHOULD receive an HTTP status code 405 Method Not
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 "/" containing a recognized RID message is handled a POST to the "/" resource containing a recognized RID message is
correctly as a RID request. Alternatively, a client requesting a handled correctly as a RID request. Alternatively, a client
POST to "/" MAY receive an HTTP status code 307 Temporary requesting a POST to "/" MAY receive an HTTP status code 307
Redirect. In this case, the location header in the HTTP response Temporary Redirect. In this case, the location header in the HTTP
will provide the URL of the appropriate RID endpoint, and the response will provide the URL of the appropriate RID endpoint, and
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. 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 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
skipping to change at page 12, line 20 skipping to change at page 12, line 28
requirements in this section are generally oriented towards any requirements in this section are generally oriented towards any
content to be published to a ROLIE server. An understanding of the content to be published to a ROLIE server. An understanding of the
Atom Syndication Format specification [RFC4287] is helpful to Atom Syndication Format specification [RFC4287] is helpful to
understand 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. The list of Atom Feeds provided by a ROLIE information items. The list of Atom Feeds provided by a ROLIE
service instance are listed in the service's Service Document through service are listed in the service's Service Document through one or
one or more app:collection elements. Each Feed document, represented more app:collection elements. Each Feed document, represented using
using the atom:feed element, contains a listing of zero or more the atom:feed element, contains a listing of zero or more Entries.
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 be checklist, a software vulnerability record). Additional Feeds can be
used to represent other collections of security automation resources. used to represent other collections of security automation resources.
As discussed in section 5.1.2, ROLIE defines specialized data
requirements for Feeds containing security automation related data.
The difference between a ROLIE and a non-ROLIE Feed can be determined
as follows:
ROLIE Feed: For an atom:feed to be considered a ROLIE Feed, the
atom:feed MUST contain only one child atom:category element with
the "scheme" attribute value of
"urn:ietf:params:rolie:category:information-type". This category
MUST have an appropriate "term" attribute value as defined in
section 7.1.1. This ensures that a given Feed corresponds to a
specific type of security automation information.
Non-ROLIE Feed: For an atom:feed to be considered a non-ROLIE Feed,
the atom:feed MUST NOT contain an atom:category element with a
"scheme" attribute value of
"urn:ietf:params:rolie:category:information-type".
By distinguishing between ROLIE and non-ROLIE Feeds in this way,
implementations supporting ROLIE can host Feeds pertaining to
security automation information alongside Feeds of other non-ROLIE
information within the same AtomPub instance. This is parallel to
the handling of collections ealier in this specification in section
5.1.2.
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 of the atom:feed element defined in RFC 4287 when used as a ROLIE
implementation. Any element not specified here inherits its Feed. Any element not specified here inherits its definition and
definition and requirements from [RFC4287]. requirements from [RFC4287].
atomFeed = atomFeed =
element atom:feed { element atom:feed {
atomCommonAttributes, atomCommonAttributes,
(atomAuthor* (atomAuthor*
& atomCategory+ & atomCategory+
& atomContributor* & atomContributor*
& atomGenerator? & atomGenerator?
& atomIcon? & atomIcon?
& atomId & atomId
& atomLink+ & atomLink+
& atomLogo? & atomLogo?
& atomRights? & atomRights?
& atomSubtitle? & atomSubtitle?
& atomTitle & atomTitle
& atomUpdated & atomUpdated
& extensionElement*), & extensionElement*),
atomEntry* atomEntry*
} }
6.1.1. Use of the "atom:category" Element The following subsections contain requirements for a ROLIE Feed.
An atom:feed can be categorized and can contain information from zero 6.1.1. Use of the "atom:category" Element
or more categories. In Atom the naming scheme and the semantic
meaning of the terms used to identify an Atom category are
application-defined.
The following restrictions are imposed on the use of the An atom:feed can contain zero or more atom:category elements. In
atom:category element when used in an atom:feed: Atom the naming scheme and the semantic meaning of the terms used to
identify an Atom category are application-defined.
o An atom:feed element MUST minimally contain a single atom:category The following are additional requirements on the use of the
element with the "scheme" attribute value of atom:category element when used in a ROLIE Feed:
"urn:ietf:params:rolie:category:information-type". This category
MUST have an appropriate "term" attribute value as defined in
section 7.1.1. This ensures that a given Feed corresponds to a
specific type of security automation information. All member
Entries in the Feed MUST represent security automation information
records of the provided information type category or categories.
o Any atom:feed element that does not contain a child atom:category o All member Entries in the Feed MUST represent security automation
element with the "scheme" attribute value of information records of the provided information type category.
"urn:ietf:params:rolie:category:information-type" MUST NOT be
considered a ROLIE Collection. This allows Feeds pertaining to
security automation information to co-exist alongside Feeds of
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-
type". This allows other category metadata to be included. type". This allows other category metadata to be included.
6.1.2. Use of the "atom:link" Element 6.1.2. Use of the "atom:link" Element
Link relations defined by the atom:link element are used to represent Link relations defined by the atom:link element are used to represent
state transitions using a stateless approach. In Atom a type of link state transitions using a stateless approach. In Atom a type of link
relationship can be defined using the "rel" attribute. relationship can be defined using the "rel" attribute.
skipping to change at page 14, line 26 skipping to change at page 14, line 33
discover additional security automation information. The "service" discover additional security automation information. The "service"
link relationship is defined in the IANA Link Relations Registry [1]. link relationship is defined in the IANA Link Relations Registry [1].
An atom:feed can contain an arbitrary number of Entries. In some An atom:feed can contain an arbitrary number of Entries. In some
cases, a complete Feed may consist of a large number of Entries. cases, a complete Feed may consist of a large number of Entries.
Additionally, as new and updated Entries are ordered at the beginning Additionally, as new and updated Entries are ordered at the beginning
of a Feed, a client may only be interested in retrieving the first N of a Feed, a client may only be interested in retrieving the first N
entries in a Feed to process only the Entries that have changed since entries in a Feed to process only the Entries that have changed since
the last retrieval of the Feed. As a practical matter, a large set the last retrieval of the Feed. As a practical matter, a large set
of Entries will likely need to be divided into more manageable of Entries will likely need to be divided into more manageable
portions. Based on RFC5005 section 3 [RFC5005], link elements SHOULD portions, or pages. Based on RFC5005 section 3 [RFC5005], link
be included in all Feeds to support paging using the following link elements SHOULD be included in all Feeds to support paging using the
relation types: following link relation types:
o "first" - Indicates that the href attribute value of the link o "first" - Indicates that the href attribute value of the link
identifies a resource IRI for the furthest preceding page of the identifies a resource IRI for the furthest preceding page of the
Feed. Feed.
o "last" - Indicates that the href attribute value of the link o "last" - Indicates that the href attribute value of the link
identifies a resource IRI for the furthest following page of the identifies a resource IRI for the furthest following page of the
Feed. Feed.
o "previous" - Indicates that the href attribute value of the link o "previous" - Indicates that the href attribute value of the link
skipping to change at page 15, line 36 skipping to change at page 15, 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
was 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 representation was last updated by adding,
updating, or deleting an Entry; or changing any metadata for the updating, or 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. defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in
section 6.1.1.
atomEntry = atomEntry =
element atom:entry { element atom:entry {
atomCommonAttributes, atomCommonAttributes,
(atomAuthor* (atomAuthor*
& atomCategory* & atomCategory*
& atomContent & atomContent
& atomContributor* & atomContributor*
& atomId & atomId
& atomLink* & atomLink*
skipping to change at page 16, line 25 skipping to change at page 16, line 27
& atomRights? & atomRights?
& atomSource? & atomSource?
& atomSummary? & atomSummary?
& atomTitle & atomTitle
& atomUpdated & atomUpdated
& rolieFormat & rolieFormat
& rolieProperty* & rolieProperty*
& extensionElement*) & extensionElement*)
} }
The following subsections contain requirements for Entries in a ROLIE
Feed.
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 An atom:content element associates its containing Entry with a
content resource identified by the src attribute.
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
} }
skipping to change at page 23, line 29 skipping to change at page 23, line 45
properties to provide valuable identifying and characterizing properties to provide valuable identifying and characterizing
information for a given information type and/or format. information for a given information type and/or format.
The namespace "urn:ietf:params:rolie:property:local" has been The namespace "urn:ietf:params:rolie:property:local" has been
reserved in the IANA ROLIE Parameters table for private use as reserved in the IANA ROLIE Parameters table for private use as
defined in [RFC5226]. Any property whose "name" attribute uses this defined in [RFC5226]. Any property whose "name" attribute uses this
as a prefix MUST be considered private use. Implementations as a prefix MUST be considered private use. Implementations
encountering such a property MUST parse the content without error, encountering such a property MUST parse the content without error,
but MAY otherwise ignore the element. but MAY otherwise ignore the element.
This document also registers the This document also registers a number of general use properties that
"urn:ietf:params:rolie:property:content-author-name" property name. can be used to expose content information in any ROLIE use case. The
This property provides an exposure point for the person or following are descriptions of how to use these registered properties:
organization that authored the content linked to in the "src"
attribute of the entry's atom:content element. urn:ietf:params:rolie:property:content-author-name The "value"
attribute of this property is a text representation indicating the
individual or organization that authored the content referenced by
the "src" attribute of the entry's atom:content element.
urn:ietf:params:rolie:property:content-id The "value" attribute of
this property is a text representation of an identifier pertaining
to or extracted from the content referenced by the "src" attribute
of the entry's atom:content element.
urn:ietf:params:rolie:property:content-published-date The "value"
attribute of this property is a text representation indicating the
original publication date of the content referenced by the "src"
attribute of the entry's atom:content element. This date may
differ from the published date of the ROLIE Entry because
publication of the content and the ROLIE Entry represent different
events. The date MUST be formatted as specified in [RFC3339].
urn:ietf:params:rolie:property:content-updated-date The "value"
attribute of this property is a text representation indicating the
date that the content, referenced by the "src" attribute of the
entry's atom:content element, was last updated. This date may
differ from the updated date of the ROLIE Entry because updates
made to the content and to the ROLIE Entry are different events.
The date MUST be formatted as specified in [RFC3339].
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 25, line 6 skipping to change at page 25, line 46
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 values are "category" {type}: The parameter type. The allowed values are "category"
or "property". "category" denotes a category extension as or "property". "category" denotes a category extension as
discussed in Section 7.1. "property" denotes a property discussed in Section 7.1. "property" denotes a property
extension as discussed in Section 7.4. extension as discussed in Section 7.4.
{label}: A required US-ASCII string that conforms to the URN {label}: A required US-ASCII string that conforms to the URN
syntax requirements (see [RFC2141]). This string must be syntax requirements (see [RFC2141]). This string must be
unique within the namespace defined by the {type} keyword. The unique within the namespace defined by the {type} keyword. The
"local" label for both the "category" and "property" types has "local" label for both the "category" and "property" types has
been reserved for private use. been reserved for private use.
Extension IRI: The identifier to use within ROLIE, which is the Extension IRI: The identifier to use within ROLIE, which is the
skipping to change at page 26, line 5 skipping to change at page 27, line 5
definition of the parameter can be found. definition of the parameter can be found.
Sub-registry: An optional field that links to an IANA sub-registry Sub-registry: An optional field that links to an IANA sub-registry
for this parameter. If the {type} is "category", the sub-registry for this parameter. If the {type} is "category", the sub-registry
must contain a "name" field whose registered values MUST be US- must contain a "name" field whose registered values MUST be US-
ASCII. The list of names are the allowed values of the "term" ASCII. The list of names are the allowed values of the "term"
attribute in the atom:category element. (See Section 7.1.2). attribute in the atom:category element. (See Section 7.1.2).
This repository has the following initial values: This repository has the following initial values:
+------------+-------------------+-------+--------------------------+ +------------+--------------------+-------+-------------------------+
| Name | Extension IRI | Refer | Sub-Registry | | Name | Extension IRI | Refer | Sub-Registry |
| | | ence | | | | | ence | |
+------------+-------------------+-------+--------------------------+ +------------+--------------------+-------+-------------------------+
| category:i | urn:ietf:params:r | This | [TO BE REMOVED: This | | category:i | urn:ietf:params:ro | This | [TO BE REMOVED: This |
| nformation | olie:category | docum | registration should take | | nformation | lie:category | docum | registration should |
| -type | :information-type | ent, | place at the following | | -type | :information-type | ent, | take place at the |
| | | Secti | location: https://www.ia | | | | Secti | following location: htt |
| | | on | na.org/assignments/rolie | | | | on | ps://www.iana.org/assig |
| | | 8.4 | /category/information- | | | | 8.4 | nments/rolie/category |
| | | | type] | | | | | /information-type] |
| property:l | urn:ietf:params:r | This | None | | property:l | urn:ietf:params:ro | This | None |
| ocal | olie:property:loc | docum | | | ocal | lie:property:local | docum | |
| | al | ent, | | | | | ent, | |
| | | Secti | | | | | Secti | |
| | | on | | | | | on | |
| | | 7.4 | | | | | 7.4 | |
| category:l | urn:ietf:params:r | This | None | | category:l | urn:ietf:params:ro | This | None |
| ocal | olie:category:loc | docum | | | ocal | lie:category:local | docum | |
| | al | ent, | | | | | ent, | |
| | | Secti | | | | | Secti | |
| | | on | | | | | on | |
| | | 7.1 | | | | | 7.1 | |
| property | urn:ietf:params:r | This | None | | property | urn:ietf:params:ro | This | None |
| :content- | olie: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 |
| :content- | lie:property | docum | |
| id | :content-id | ent, | |
| | | Secti | |
| | | on | |
| | | 7.4 | |
| property | urn:ietf:params:ro | This | None |
| :content- | lie:property | docum | |
| published- | :content- | ent, | |
| date | published-date | Secti | |
| | | on | |
| | | 7.4 | |
| property | urn:ietf:params:ro | This | None |
| :content- | lie:property | docum | |
| updated- | :content-updated- | ent, | |
| date | date | Secti | |
| | | on | |
| | | 7.4 | |
+------------+--------------------+-------+-------------------------+
8.4. ROLIE Security Resource Information Type Sub-Registry 8.4. ROLIE Security Resource Information Type Sub-Registry
A new sub-registry has been created to store ROLIE information type A new sub-registry has been created to store ROLIE information type
values. values.
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
skipping to change at page 28, line 5 skipping to change at page 29, line 22
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.
All security measures SHOULD be enforced at the source, that is, a To protect the confidentiality of a given resource provided by a
provider SHOULD NOT return any Feed content or member Entry content ROLIE implementation, requests for retrieval of the resource need to
for which the client identity has not been specifically be authenticated to prevent unauthorized users from accessing the
authenticated, authorized, and audited. resource (see section 5.4). It can also be useful to log and audit
access to sensitive resources to verify that proper access controls
remain in place over time.
The approach described herein is based upon all policy enforcements The approach described herein is based upon all policy enforcements
being implemented at the point when a resource representation is being implemented at the point when a resource representation is
created. As such, producers sharing cyber security information using created. As such, producers sharing cyber security information using
this specification must take care to authenticate their HTTP clients this specification must take care to authenticate their HTTP clients
using a suitably strong user authentication mechanism. Sharing using a suitably strong user authentication mechanism. Sharing
communities that are exchanging information on well-known indicators communities that are exchanging information on well-known indicators
and incidents for purposes of public education may choose to rely and incidents for purposes of public education may choose to rely
upon HTTP Authentication or similar. However, sharing communities upon HTTP Authentication or similar. However, sharing communities
that are engaged in sensitive collaborative analysis and/or that are engaged in sensitive collaborative analysis and/or
skipping to change at page 28, line 39 skipping to change at page 30, line 9
Dependency on a trusted third party identity provider implies that Dependency on a trusted third party identity provider implies that
appropriate care must be exercised to sufficiently secure the appropriate care must be exercised to sufficiently secure the
Identity provider. Any attacks on the federated identity system Identity provider. Any attacks on the federated identity system
would present a risk to the consortium, as a relying party. would present a risk to the consortium, as a relying party.
Potential mitigations include deployment of a federation-aware Potential mitigations include deployment of a federation-aware
identity provider that is under the control of the information identity provider that is under the control of the information
sharing consortium, with suitably stringent technical and management sharing consortium, with suitably stringent technical and management
controls. controls.
Authorization of resource representations is the responsibility of Authorization of resource representations is the responsibility of
the source system, i.e. based on the authenticated user identity the source system, i.e. based on the authenticated user identity
associated with an HTTP(S) request. The required authorization associated with an HTTP(S) request. The required authorization
policies that are to be enforced must therefore be managed by the policies that are to be enforced must therefore be managed by the
security administrators of the source system. Various authorization security administrators of the source system. Various authorization
architectures would be suitable for this purpose, such as RBAC [3] architectures would be suitable for this purpose, such as RBAC [3]
and/or ABAC, as embodied in XACML [XACML]. In particular, and/or ABAC, as embodied in XACML [XACML]. In particular,
implementers adopting XACML may benefit from the capability to implementers adopting XACML may benefit from the capability to
represent their authorization policies in a standardized, represent their authorization policies in a standardized,
interoperable format. Note that implementers are free to choose any interoperable format. Note that implementers are free to choose any
suitable authorization mechanism that is capable of fulfilling the suitable authorization mechanism that is capable of fulfilling the
policy enforcement requirements relevant to their consortium and/or policy enforcement requirements relevant to their consortium and/or
skipping to change at page 30, line 34 skipping to change at page 32, line 9
The authors gratefully acknowledge the valuable contributions of Tom The authors gratefully acknowledge the valuable contributions of Tom
Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These
individuals provided detailed review comments on earlier drafts, and individuals provided detailed review comments on earlier drafts, and
made many suggestions that have helped to improve this document. made many suggestions that have helped to improve this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[relax-NG]
Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002,
<https://www.oasis-open.org/committees/relax-ng/compact-
20021121.html>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<http://www.rfc-editor.org/info/rfc20>. <http://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, DOI 10.17487/RFC3688, January 2004,
<http://www.rfc-editor.org/info/rfc3688>. <http://www.rfc-editor.org/info/rfc3688>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, DOI 10.17487/RFC4287, Syndication Format", RFC 4287, DOI 10.17487/RFC4287,
December 2005, <http://www.rfc-editor.org/info/rfc4287>. December 2005, <http://www.rfc-editor.org/info/rfc4287>.
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using
Transport Layer Security (TLS) with Network News Transfer
Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
2006, <http://www.rfc-editor.org/info/rfc4642>.
[RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005,
DOI 10.17487/RFC5005, September 2007, DOI 10.17487/RFC5005, September 2007,
<http://www.rfc-editor.org/info/rfc5005>. <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>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <http://www.rfc-editor.org/info/rfc7970>.
[RFC6546] Trammell, B., "Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS", RFC 6546,
DOI 10.17487/RFC6546, April 2012,
<http://www.rfc-editor.org/info/rfc6546>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
2003, <http://www.rfc-editor.org/info/rfc3553>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<http://www.rfc-editor.org/info/rfc7589>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using
Transport Layer Security (TLS) with Network News Transfer
Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October
2006, <http://www.rfc-editor.org/info/rfc4642>.
[RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known
Uniform Resource Identifiers (URIs)", RFC 5785, Uniform Resource Identifiers (URIs)", RFC 5785,
DOI 10.17487/RFC5785, April 2010, DOI 10.17487/RFC5785, April 2010,
<http://www.rfc-editor.org/info/rfc5785>. <http://www.rfc-editor.org/info/rfc5785>.
[relax-NG] [RFC6546] Trammell, B., "Transport of Real-time Inter-network
Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002, Defense (RID) Messages over HTTP/TLS", RFC 6546,
<https://www.oasis-open.org/committees/relax-ng/compact- DOI 10.17487/RFC6546, April 2012,
20021121.html>. <http://www.rfc-editor.org/info/rfc6546>.
[RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the
NETCONF Protocol over Transport Layer Security (TLS) with
Mutual X.509 Authentication", RFC 7589,
DOI 10.17487/RFC7589, June 2015,
<http://www.rfc-editor.org/info/rfc7589>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <http://www.rfc-editor.org/info/rfc7970>.
[W3C.REC-xml-names-20091208]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>.
12.2. Informative References 12.2. Informative References
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>. May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000, DOI 10.17487/RFC2782, February 2000,
<http://www.rfc-editor.org/info/rfc2782>. <http://www.rfc-editor.org/info/rfc2782>.
[RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, Information Models and Data Models", RFC 3444,
DOI 10.17487/RFC3444, January 2003, DOI 10.17487/RFC3444, January 2003,
<http://www.rfc-editor.org/info/rfc3444>. <http://www.rfc-editor.org/info/rfc3444>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <http://www.rfc-editor.org/info/rfc5234>.
[SAML-bind]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard saml-bindings-
2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.
[SAML-core] [SAML-core]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"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
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005, Standard OASIS.saml-profiles-2.0-os, March 2005,
<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]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Standard saml-bindings-
2.0-os, March 2005, <http://docs.oasis-
open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf>.
[XACML] Rissanen, E., "eXtensible Access Control Markup Language [XACML] Rissanen, E., "eXtensible Access Control Markup Language
(XACML) Version 3.0", August 2010, <http://docs.oasis- (XACML) Version 3.0", August 2010, <http://docs.oasis-
open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>. open.org/xacml/3.0/xacml-3.0-core-spec-cs-01-en.pdf>.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
top.htm>.
12.3. URIs 12.3. URIs
[1] https://www.iana.org/assignments/link-relations/link- [1] https://www.iana.org/assignments/link-relations/link-
relations.xhtml relations.xhtml
[2] https://www.iana.org/assignments/link-relations/link- [2] https://www.iana.org/assignments/link-relations/link-
relations.xhtml relations.xhtml
[3] http://csrc.nist.gov/groups/SNS/rbac/ [3] http://csrc.nist.gov/groups/SNS/rbac/
skipping to change at page 40, 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-08 since draft-ietf-mile-rolie-07
revision:
Reworked "usage of app:collection" and "usage of atom:feed"
sections to clarify ROLIE vs non-ROLIE collections/feeds
Removed requirement from Security Considerations that was a
duplicate of text earlier in the document
TLS requirement clarifications around mutal authentication
Clarified requirements around support for the "/" resource
Added IANA property registrations for content-id, content-
published-date, and content-updated-date that can be used across
all ROLIE extensions to increase consistency/interop
Assorted editorial changes
Changes in draft-ietf-mile-rolie-07 since draft-ietf-mile-rolie-06 Changes in draft-ietf-mile-rolie-07 since draft-ietf-mile-rolie-06
version, March 13, 2017 to TODO, 2017 revision:
Added /.well-known/ registration and requirement to service Condensed and re-focused Sections 1 and 4 to be more concise.
Added /.well-known/ registration and requirement for service
discovery. discovery.
Condensed and re-focused Sections 1 and 4 to be more concise. Added local category, property namespace, and additional property
registrations
Added privacy considerations section. Added privacy considerations section.
Made a number of editorial changes as per WGLC review. Made a number of editorial changes as per WGLC review.
Changes in draft-ietf-mile-rolie-06 since draft-ietf-mile-rolie-05 Changes in draft-ietf-mile-rolie-06 since draft-ietf-mile-rolie-05
version, November 2, 2016 to March 13, 2017 revision:
Changed to standards track Changed to standards track
Added the rolie:property element Added the rolie:property element
Fixed references (Normative vs Informative) Fixed references (Normative vs Informative)
Set Service and Category document URL template requirements Set Service and Category document URL template requirements
Fixed XML snippets in examples Fixed XML snippets in examples
Changes in draft-ietf-mile-rolie-05 since draft-ietf-mile-rolie-04 Changes in draft-ietf-mile-rolie-05 since draft-ietf-mile-rolie-04
version, October 21, 2016 to November 2, 2016 revision:
Added ROLIE specific terminology to section 2 Added ROLIE specific terminology to section 2
Added AtomPub Category Document in section 5.2 Added AtomPub Category Document in section 5.2
Edited document, improving consistency in terminology usage and Edited document, improving consistency in terminology usage and
capitalization of key terms, as well as enhancing clarity. capitalization of key terms, as well as enhancing clarity.
Removed unused format parameter type in section 8.3 Removed unused format parameter type in section 8.3
Schema removed, the normative schema consists of the snippets in Schema removed, the normative schema consists of the snippets in
the requirements sections. the requirements sections.
Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-03 Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-03
version, July 8, 2016 to October 31, 2016 revision:
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.
o Fixed both internal section and external document referencing. o Fixed both internal section and external document referencing.
o Removed XACML Guidance Appendix. This will be added to a future o Removed XACML Guidance Appendix. This will be added to a future
skipping to change at page 41, line 17 skipping to change at page 43, line 38
o Examples and References updated. o Examples and References updated.
o Schema created. o Schema created.
o Fixed both internal section and external document referencing. o Fixed both internal section and external document referencing.
o Removed XACML Guidance Appendix. This will be added to a future o Removed XACML Guidance Appendix. This will be added to a future
draft on ROLIE Authentication and Access Control. draft on ROLIE Authentication and Access Control.
Changes made in draft-ietf-mile-rolie-03 since draft-ietf-mile- Changes made in draft-ietf-mile-rolie-03 since draft-ietf-mile-
rolie-02 version, May 27, 2016 to July 8, 2015 rolie-02 revision:
o Atom Syndication and Atom Pub requirements split and greatly o Atom Syndication and Atom Pub requirements split and greatly
expanded for increased justification and technical specification. expanded for increased justification and technical specification.
o Reintroduction and reformatting of some use case examples in order o Reintroduction and reformatting of some use case examples in order
to provide some guidance on use. to provide some guidance on use.
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 revision:
o All CSIRT and IODEF/RID material moved to companion CSIRT document o All CSIRT and IODEF/RID material moved to companion CSIRT document
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
skipping to change at page 42, line 6 skipping to change at page 44, line 25
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
accomplish a broader scope and greater readability accomplish a broader scope and greater readability
o Removed any requirements from the Background section and, if not o Removed any requirements from the Background section and, if not
already stated, placed them in the requirements section already stated, placed them in the requirements section
o Re-formatted the requirements section to make it clearer that it o Re-formatted the requirements section to make it clearer that it
contains the lions-share of the requirements of the specification contains the lions-share of the requirements of the specification
Changes made in draft-ietf-mile-rolie-01 since draft-field-mile- Changes made in draft-ietf-mile-rolie-01 since draft-field-mile-
rolie-02 version, August 15, 2013 to December 2, 2015: rolie-02 revision:
o Added section specifying the use of RFC5005 for Archive and Paging o Added section specifying the use of RFC5005 for Archive and Paging
of Feeds. of Feeds.
o Added section describing use of atom categories that correspond to o Added section describing use of atom categories that correspond to
IODEF expectation class and impact classes. See: normative- IODEF expectation class and impact classes. See: normative-
expectation-impact expectation-impact
o Dropped references to adoption of a MILE-specific HTTP media type o Dropped references to adoption of a MILE-specific HTTP media type
parameter. parameter.
 End of changes. 62 change blocks. 
212 lines changed or deleted 312 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/