draft-ietf-mile-rolie-12.txt   draft-ietf-mile-rolie-13.txt 
MILE Working Group J. Field MILE Working Group J. Field
Internet-Draft Pivotal Internet-Draft Pivotal
Intended status: Standards Track S. Banghart Intended status: Standards Track S. Banghart
Expires: April 27, 2018 D. Waltermire Expires: April 29, 2018 D. Waltermire
NIST NIST
October 24, 2017 October 26, 2017
Resource-Oriented Lightweight Information Exchange Resource-Oriented Lightweight Information Exchange
draft-ietf-mile-rolie-12 draft-ietf-mile-rolie-13
Abstract Abstract
This document defines a resource-oriented approach for security This document defines a resource-oriented approach for security
automation information publication, discovery, and sharing. Using automation information publication, discovery, and sharing. Using
this approach, producers may publish, share, and exchange this approach, producers may publish, share, and exchange
representations of software descriptors, security incidents, attack representations of software descriptors, security incidents, attack
indicators, software vulnerabilities, configuration checklists, and indicators, software vulnerabilities, configuration checklists, and
other security automation information as web-addressable resources. other security automation information as web-addressable resources.
Furthermore, consumers and other stakeholders may access and search Furthermore, consumers and other stakeholders may access and search
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2018. This Internet-Draft will expire on April 29, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 11, line 15 skipping to change at page 11, line 15
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
support appropriate authorization checking for all resource accesses, support appropriate authorization checking for all resource accesses,
including individual Atom Entries, Atom Feeds, and Atom Service including individual Atom Entries, Atom Feeds, and Atom Service
Documents. Documents.
5.5. / (forward slash) Resource URL 5.5. / (forward slash) Resource URL
The "/" resource MAY be supported for compatibility with existing The "/" resource MAY be supported for compatibility with existing
deployments that are using Transport of Real-time Inter-network deployments that are using Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546]. Defense (RID) Messages over HTTP/TLS [RFC6546]. The following
requirements apply only to implementations supporting RFC 6546.
The following additional requirements only apply if a implementation The following additional requirements only apply if a implementation
is supporting the "/" resource as described above: is supporting the "/" resource as described above:
o Consistent with RFC6546 errata, a client requesting a GET on the o Consistent with RFC6546 errata, a client requesting a GET on the
"/" resource SHOULD receive an HTTP status code 405 Method Not "/" resource SHOULD receive an HTTP status code 405 Method Not
Allowed. Allowed.
o An implementation MAY provide full support for [RFC6546] such that o An implementation MAY provide full support for [RFC6546] such that
a POST to the "/" resource containing a recognized RID message is a POST to the "/" resource containing a recognized RID message is
handled correctly as a RID request. Alternatively, a client handled correctly as a RID request. Alternatively, a client
requesting a POST to "/" MAY receive an HTTP status code 307 requesting a POST to "/" MAY receive an HTTP status code 307
Temporary Redirect. In this case, the location header in the HTTP Temporary Redirect. In this case, the location header in the HTTP
response will provide the URL of the appropriate RID endpoint, and response will provide the URL of the appropriate RID endpoint, and
the client may repeat the POST method at the indicated location. the client may repeat the POST method at the indicated location.
If the "/" resource is unsupported, then a request for this resource If RFC 6546 is unsupported, then a request for the "/" resource may
MAY be handled as deemed appropriate by the server. be handled as deemed appropriate by the server.
5.6. HTTP methods 5.6. HTTP methods
Servers MAY accept request methods beyond those specified in this Servers MAY accept request methods beyond those specified in this
document. document.
Clients MUST be capable of recognizing and processing any standard Clients MUST be capable of recognizing and processing any standard
HTTP status code, as defined in [RFC5023] Section 5. HTTP status code, as defined in [RFC5023] Section 5.
6. ROLIE Requirements for the Atom Syndication Format 6. ROLIE Requirements for the Atom Syndication Format
skipping to change at page 16, line 48 skipping to change at page 16, line 48
representation of the atom:content element defined in [RFC4287]: representation of the atom:content element defined in [RFC4287]:
atomContent = atomContent =
element atom:content { element atom:content {
atomCommonAttributes, atomCommonAttributes,
attribute type { atomMediaType }, attribute type { atomMediaType },
attribute src { atomUri }, attribute src { atomUri },
empty empty
} }
This restricts atomContent in ROLIE to the atomOutofLine forumulation This restricts atomContent in ROLIE to the atomOutofLine formulation
presented in[RFC4287]. presented in[RFC4287].
The type attribute MUST identify the serialization type of the The type attribute MUST identify the serialization type of the
content, for example, application/xml or application/json. A content, for example, application/xml or application/json. A
prefixed media type MAY be used to reflect a specific model used with prefixed media type MAY be used to reflect a specific model used with
a given serialization approach (e.g., application/rdf+xml). The src a given serialization approach (e.g., application/rdf+xml). The src
attribute MUST be an URI that can be dereferenced to retrieve the attribute MUST be an URI that can be dereferenced to retrieve the
related content data. related content data.
6.2.2. Use of the "atom:link" Element 6.2.2. Use of the "atom:link" Element
skipping to change at page 18, line 19 skipping to change at page 18, line 19
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
namespace URI, or an identifier that represents a serialized JSON namespace URI, or an identifier that represents a serialized JSON
model. The URI used for the "ns" attribute value MUST be an absolute model. The URI used for the "ns" attribute MUST be absolute. The
or opaque URI. The resource identified by the URI need not be resource identified by the URI need not be resolvable.
resolvable.
The rolie:format element MAY provide a "version" attribute that The rolie:format element MAY provide a "version" attribute that
identifies the version of the format used for the related identifies the version of the format used for the related
atom:content. atom:content.
The rolie:format element MAY provide a "schema-location" attribute The rolie:format element MAY provide a "schema-location" attribute
that is a URI that identifies a schema resource that can be used to that 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" attribute, which The rolie:format element MAY provide a "schema-type" attribute, which
is a mime type identifying the format of the schema resource is a media type (as described in [RFC2045] identifying the format of
identified by the "schema-location" attribute. the schema resource identified by the "schema-location" attribute.
The following nominal example shows how these attributes describe the The following nominal example shows how these attributes describe the
format of the content: format of the content:
<rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0" <rolie:format ns="urn:ietf:params:xml:ns:iodef-2.0"
version="2.0" version="2.0"
schema-location= schema-location=
"https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd" "https://www.iana.org/assignments/xml-registry/schema/iodef-2.0.xsd"
schema-type-"text/xml"/> schema-type="text/xml"/>
The previous element provides an indication that the content of the The previous element provides an indication that the content of the
given entry is using the IODEF v2 format. given entry is using the IODEF v2 format.
6.2.4. Use of the rolie:property Element 6.2.4. Use of the rolie:property Element
An atom:category element provides a way to associate a name/value An atom:category element provides a way to associate a name/value
pair of categorical information using the scheme and term attributes pair of categorical information using the scheme and term attributes
to represent the name, and the label attribute to represent the to represent the name, and the label attribute to represent the
value. When used in this way an atom:category allows a specific value. When used in this way an atom:category allows a specific
skipping to change at page 19, line 33 skipping to change at page 19, line 32
empty empty
} }
The name attribute provides a URI that identifies the namespace and The name attribute provides a URI that identifies the namespace and
name of the property as a URI. name of the property as a URI.
The value attribute is text that provides a value for the property The value attribute is text that provides a value for the property
identified by the name attribute. identified by the name attribute.
For example, the nominal element <rolie:property For example, the nominal element <rolie:property
name="urn:ietf:params:rolie:property:csirt-iodef-id" value="12345"/> name="urn:ietf:params:rolie:property:content-id" value="12345"/>
would expose an IODEF ID value contained in a given entry's content. 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 The name used in the example also demonstrates the use of a
registered ROLIE property extension, which is described in registered ROLIE property extension, which is described in
Section 7.4. Section 7.4.
Implementations MAY use locally defined and namespaced elements in an Implementations MAY use locally defined and namespaced elements in an
Entry in order to provide additional information. Clients that do Entry in order to provide additional information. Clients that do
not recognize a property with an unregistered name attribute MAY not recognize a property with an unregistered name attribute MUST
ignore the rolie:property. ignore the rolie:property, that is, the client MUST NOT fail parsing
content that contains an unrecognized property.
6.2.5. Requirements for a Standalone Entry 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 an atom:link element with rel="collection" and o The Entry MUST have an atom:link element with rel="collection" and
href="[URI of the containing Collection]". This allows the Feed href="[URI 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
skipping to change at page 24, line 8 skipping to change at page 24, line 8
urn:ietf:params:rolie:property:content-author-name The "value" urn:ietf:params:rolie:property:content-author-name The "value"
attribute of this property is a text representation indicating the attribute of this property is a text representation indicating the
individual or organization that authored the content referenced by individual or organization that authored the content referenced by
the "src" attribute of the entry's atom:content element. This the "src" attribute of the entry's atom:content element. This
author may differ from the atom:author when the author of the author may differ from the atom:author when the author of the
content and the entry are different people or entities. content and the entry are different people or entities.
urn:ietf:params:rolie:property:content-id The "value" attribute of urn:ietf:params:rolie:property:content-id The "value" attribute of
this property is a text representation of an identifier pertaining this property is a text representation of an identifier pertaining
to or extracted from the content referenced by the "src" attribute to or extracted from the content referenced by the "src" attribute
of the entry's atom:content element. of the entry's atom:content element. For example, if the
atom:entry's atom:content element links to an IODEF document, the
"content-id" value would be an identifier of that IODEF document.
urn:ietf:params:rolie:property:content-published-date The "value" urn:ietf:params:rolie:property:content-published-date The "value"
attribute of this property is a text representation indicating the attribute of this property is a text representation indicating the
original publication date of the content referenced by the "src" original publication date of the content referenced by the "src"
attribute of the entry's atom:content element. This date may attribute of the entry's atom:content element. This date may
differ from the published date of the ROLIE Entry because differ from the published date of the ROLIE Entry because
publication of the content and the ROLIE Entry represent different publication of the content and the ROLIE Entry represent different
events. The date MUST be formatted as specified in [RFC3339]. events. The date MUST be formatted as specified in [RFC3339].
urn:ietf:params:rolie:property:content-updated-date The "value" urn:ietf:params:rolie:property:content-updated-date The "value"
skipping to change at page 25, line 32 skipping to change at page 25, line 33
Index value: See Section 8.3 Index value: See Section 8.3
8.3. ROLIE URN Parameters 8.3. ROLIE URN Parameters
A new top-level registry has been created, entitled "Resource A new top-level registry has been created, entitled "Resource
Oriented Lightweight Information Exchange (ROLIE) URN Parameters". Oriented Lightweight Information Exchange (ROLIE) URN Parameters".
[TO BE REMOVED: This registration should take place at the following [TO BE REMOVED: This registration should take place at the following
location: https://www.iana.org/assignments/rolie] location: https://www.iana.org/assignments/rolie]
Registration in the ROLIE URN Parameters registry is via the Registration in the ROLIE URN Parameters registry is via the
Specification Required policy [RFC8126]. Designated Expert reviews Specification Required policy [RFC8126]. Registration requests must
should be routed through the MILE WG mailing list. Failing this, the be sent to both the MILE WG mailing list (mile@ietf.org) and IANA.
Designated Expert will be assigned by the IESG. IANA will forward registration requests to the Designated Expert.
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.
skipping to change at page 32, line 9 skipping to change at page 32, line 9
[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/ <https://www.oasis-open.org/committees/relax-ng/
compact-20021121.html>. compact-20021121.html>.
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969, RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>. <https://www.rfc-editor.org/info/rfc20>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>. <https://www.rfc-editor.org/info/rfc3339>.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
skipping to change at page 43, line 7 skipping to change at page 43, line 7
src="https://example.org/provider/vulns/123456/data"> src="https://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-12 since draft-ietf-mile-rolie-11
revision:
Addressed comments from IESG review.
Changes in draft-ietf-mile-rolie-11 since draft-ietf-mile-rolie-09 Changes in draft-ietf-mile-rolie-11 since draft-ietf-mile-rolie-09
revision: revision:
Incorporated ART last call review and AD review changes Incorporated ART last call review and AD review changes.
Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08 Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08
revision: revision:
TLS requirements changed to clarify TLS versioning and TLS requirements changed to clarify TLS versioning and
recommendations recommendations
Informative references and textual discussion added to Security Informative references and textual discussion added to Security
Considerations around HTTP Authentication and content Signing/ Considerations around HTTP Authentication and content Signing/
Encryption. Encryption.
 End of changes. 17 change blocks. 
22 lines changed or deleted 35 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/