idnits 2.17.1 draft-ietf-mile-rolie-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 19, 2017) is 2379 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1595 -- Looks like a reference, but probably isn't: '2' on line 1598 -- Looks like a reference, but probably isn't: '3' on line 1601 -- Looks like a reference, but probably isn't: '4' on line 1604 == Unused Reference: 'RFC4642' is defined on line 1440, but no explicit reference was found in the text == Unused Reference: 'RFC5280' is defined on line 1453, but no explicit reference was found in the text == Unused Reference: 'RFC7589' is defined on line 1475, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5785 (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-21 Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MILE Working Group J. Field 3 Internet-Draft Pivotal 4 Intended status: Standards Track S. Banghart 5 Expires: April 22, 2018 D. Waltermire 6 NIST 7 October 19, 2017 9 Resource-Oriented Lightweight Information Exchange 10 draft-ietf-mile-rolie-11 12 Abstract 14 This document defines a resource-oriented approach for security 15 automation information publication, discovery, and sharing. Using 16 this approach, producers may publish, share, and exchange 17 representations of software descriptors, security incidents, attack 18 indicators, software vulnerabilities, configuration checklists, and 19 other security automation information as web-addressable resources. 20 Furthermore, consumers and other stakeholders may access and search 21 this security information as needed, establishing a rapid and on- 22 demand information exchange network for restricted internal use or 23 public access repositories. This specification extends the Atom 24 Publishing Protocol and Atom Syndication Format to transport and 25 share security automation resource representations. 27 Contributing to this document 29 The source for this draft is being maintained on GitHub. Suggested 30 changes should be submitted as pull requests at 31 . Instructions are on that page 32 as well. Editorial changes can be managed in GitHub, but any 33 substantial issues need to be discussed on the MILE mailing list. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 22, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. XML-related Conventions . . . . . . . . . . . . . . . . . . . 4 71 3.1. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . 5 73 4. Background and Motivation . . . . . . . . . . . . . . . . . . 5 74 5. ROLIE Requirements for the Atom Publishing Protocol . . . . . 6 75 5.1. AtomPub Service Documents . . . . . . . . . . . . . . . . 7 76 5.1.1. Use of the "app:workspace" Element . . . . . . . . . 7 77 5.1.2. Use of the "app:collection" Element . . . . . . . . . 8 78 5.1.3. Service Document Discovery . . . . . . . . . . . . . 9 79 5.2. Category Documents . . . . . . . . . . . . . . . . . . . 9 80 5.3. Transport Layer Security . . . . . . . . . . . . . . . . 9 81 5.4. User Authentication and Authorization . . . . . . . . . . 10 82 5.5. / (forward slash) Resource URL . . . . . . . . . . . . . 10 83 5.6. HTTP methods . . . . . . . . . . . . . . . . . . . . . . 11 84 6. ROLIE Requirements for the Atom Syndication Format . . . . . 11 85 6.1. Use of the "atom:feed" element . . . . . . . . . . . . . 11 86 6.1.1. Use of the "atom:category" Element . . . . . . . . . 12 87 6.1.2. Use of the "atom:link" Element . . . . . . . . . . . 13 88 6.1.3. Use of the "atom:updated" Element . . . . . . . . . . 14 89 6.2. Use of the "atom:entry" Element . . . . . . . . . . . . 14 90 6.2.1. Use of the "atom:content" Element . . . . . . . . . . 15 91 6.2.2. Use of the "atom:link" Element . . . . . . . . . . . 16 92 6.2.3. Use of the "rolie:format" Element . . . . . . . . . . 16 93 6.2.4. Use of the rolie:property Element . . . . . . . . . . 17 94 6.2.5. Requirements for a Standalone Entry . . . . . . . . . 18 95 7. Available Extension Points Provided by ROLIE . . . . . . . . 19 96 7.1. The Category Extension Point . . . . . . . . . . . . . . 19 97 7.1.1. General Use of the "atom:category" Element . . . . . 20 98 7.1.2. Identification of Security Automation Information 99 Types . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7.2. The "rolie:format" Extension Point . . . . . . . . . . . 21 101 7.3. The Link Relation Extension Point . . . . . . . . . . . . 22 102 7.4. The "rolie:property" Extension Point . . . . . . . . . . 22 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 104 8.1. XML Namespaces and Schema URNs . . . . . . . . . . . . . 23 105 8.2. ROLIE URN Sub-namespace . . . . . . . . . . . . . . . . . 24 106 8.3. ROLIE URN Parameters . . . . . . . . . . . . . . . . . . 24 107 8.4. ROLIE Security Resource Information Type Sub-Registry . . 26 108 8.5. Well-Known URI Registrations . . . . . . . . . . . . . . 27 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 110 10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29 111 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 112 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 113 12.1. Normative References . . . . . . . . . . . . . . . . . . 30 114 12.2. Informative References . . . . . . . . . . . . . . . . . 33 115 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35 116 Appendix A. Relax NG Compact Schema for ROLIE . . . . . . . . . 35 117 Appendix B. Examples of Use . . . . . . . . . . . . . . . . . . 36 118 B.1. Service Discovery . . . . . . . . . . . . . . . . . . . . 36 119 B.2. Feed Retrieval . . . . . . . . . . . . . . . . . . . . . 39 120 B.3. Entry Retrieval . . . . . . . . . . . . . . . . . . . . . 41 121 Appendix C. Change History . . . . . . . . . . . . . . . . . . . 42 122 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 124 1. Introduction 126 This document defines a resource-oriented approach to security 127 automation information sharing that follows the Representational 128 State Transfer (REST) architectural style [REST]. In this approach, 129 computer security resources are maintained in web-accessible 130 repositories structured as Atom Syndication Format [RFC4287] Feeds. 131 Within a given Feed, which may be requested by the consumer, 132 representations of specific types of security automation information 133 are organized, categorized, and described. Furthermore, all 134 collections available to a given user are discoverable, allowing the 135 consumer to search all available content they are authorized to view, 136 and to locate and request the desired information resources. Through 137 use of granular authentication and access controls, only authorized 138 consumers may be permitted the ability to read or write to a given 139 Feed. 141 The goal of this approach is to increase the communication and 142 sharing of security information between providers and consumers that 143 can be used to automate security processes (e.g., incident reports, 144 vulnerability assessments, configuration checklists, and other 145 security automation information). Such sharing allows human 146 operators and computer systems to leverage this standardized 147 communication system to gather information that supports the 148 automation of security processes. 150 To support new types of security automation information being used as 151 time goes on, this specification defines a number of extension points 152 that can be used either privately or globally. These global 153 extensions are IANA registered by ROLIE extension specifications, and 154 provide enhanced interoperability for new use cases and domains. 155 Sections 5 and 6 of this document define the core requirements of all 156 implementations of this specification, and is resource representation 157 agnostic. An overview of the extension system is provided in 158 Section 7. Implementers seeking to provide support for specific 159 security automation information types should refer to the 160 specification for that domain described by the IANA registry found in 161 section 8.4. 163 2. Terminology 165 The key words "MUST," "MUST NOT," "REQUIRED," "SHALL," "SHALL NOT," 166 "SHOULD," "SHOULD NOT," "RECOMMENDED," "MAY," and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 The previous key words are used in this document to define the 170 conformance requirements for implementations of this specification. 171 This document does not give any recommendations for the use of ROLIE, 172 it only provides conformance requirements for implementations of this 173 specification. 175 Definitions for some of the common computer security-related 176 terminology used in this document can be found in Section 2 of 177 [RFC7970]. 179 The following terms are unique to this specification: 181 Information Type A class of security automation information having 182 one or more associated data models. Often such security 183 automation information is used in the automation of a security 184 process. See section 7.1.2 for more information. 186 3. XML-related Conventions 188 3.1. XML Namespaces 190 This specification uses XML Namespaces [W3C.REC-xml-names-20091208] 191 to uniquely identify XML element names. It uses the following 192 namespace prefix mappings for the indicated namespace URI: 194 "app" is used for the "http://www.w3.org/2007/app" namespace 195 defined in [RFC5023]. 197 "atom" is used for the "http://www.w3.org/2005/Atom" namespace 198 defined in [RFC4287]. 200 "rolie" is used for the "urn:ietf:params:xml:ns:rolie:1.0" 201 namespace defined in section 8.1 of this specification. 203 3.2. RELAX NG Compact Schema 205 Some sections of this specification are illustrated with fragments of 206 a non-normative RELAX NG Compact schema [relax-NG]. The text of this 207 specification provides the definition of conformance. Schema for the 208 "http://www.w3.org/2007/app" and "http://www.w3.org/2005/Atom" 209 namespaces appear in RFC5023 appendix B [RFC5023] and RFC4287 210 appendix B [RFC4287] respectively. 212 A complete informative RELAX NG Compact Schema for the new elements 213 introduced by ROLIE is provided in Appendix A. 215 4. Background and Motivation 217 In order to automate security process, tools need access to 218 sufficient sources of structured security information that can be 219 used to drive security processes. Thus, security information sharing 220 is one of the core components of automating security processes. 221 Vulnerabilities, configurations, software identification, security 222 incidents, and patch data are just a few of the classes of 223 information that are shared today to enable effective security on a 224 wide scale. However, as the scale of defense broadens as networks 225 become larger and more complex, and the volume of information to 226 process makes humans-in-the-loop difficult to scale, the need for 227 automation and machine-to-machine communication becomes increasingly 228 critical. 230 ROLIE seeks to address this need by providing four major information 231 sharing benefits: 233 Extensible information type categories and format agnosticism: ROLIE 234 is not bound to any given data format or category of information. 235 Instead, information categories are extensible, and entries 236 declare the format of the referenced data. In cases where several 237 formats or serializations are available, ROLIE can use link 238 relations to communicate how a consumer can access these formats. 239 For example, clients may request that a given resource 240 representation be returned as XML, JSON, or in some other format 241 or serialization. This approach allows the provider to support 242 multiple, compatible formats allowing the consumer to select the 243 most suitable version. 245 Open and distributed information sharing: Using the Atom Publishing 246 Protocol, ROLIE feeds can easily aggregate feeds and accept 247 information POSTed to them from other sources. Webs of 248 communicating ROLIE servers form ad-hoc sharing communities, 249 increasing data availability and the ability to correlate linked 250 data across sources for participating consumers. ROLIE servers 251 needn't be distributed however, as large ROLIE repositories can 252 function as a central or federated collections. 254 Stateless communication model: ROLIE, as a RESTful system, is 255 stateless. That is, the server doesn't keep track of client 256 sessions, but rather uses link relations for state transitions. 257 In practice, this means that any consumer can find and share 258 information at any organizational level and at any time without 259 needing to execute a long series of requests. 261 Information discovery and navigation: ROLIE provides a number of 262 mechanisms to allow clients to programmatically discover and 263 navigate collections of information in order to dynamically 264 discover new or revised content. Extensible information types and 265 other categories provide one way of determining content that is 266 desirable. Link elements, each with a target URI and an 267 established relationship type, provide a means for ROLIE providers 268 to link other information that is relevant to the current entry or 269 feed. 271 These benefits result in an information sharing protocol that is 272 lightweight, interactive, open, and most importantly, machine 273 readable. 275 The requirements in this specification are broken into two major 276 sections, extensions to the Atom Publishing Protocol (AtomPub) 277 [RFC5023], and extensions to the Atom Syndication Format [RFC4287]. 278 All normative requirements in AtomPub and Atom Syndication are 279 inherited from their respective specifications, and apply here unless 280 the requirement is explicitly overridden in this document. In this 281 way, this document may upgrade the requirement (e.g., make a SHOULD a 282 MUST), but will never downgrade a given requirement (e.g., make a 283 MUST a SHOULD). 285 5. ROLIE Requirements for the Atom Publishing Protocol 287 This section describes a number of restrictions of and extensions to 288 the Atom Publishing Protocol (AtomPub) [RFC5023] that define the use 289 of that protocol in the context of a ROLIE-based solution. The 290 normative requirements in this section are generally oriented towards 291 client and server implementations. An understanding of the Atom 292 Publishing Protocol specification [RFC5023] is helpful to understand 293 the requirements in this section. 295 5.1. AtomPub Service Documents 297 As described in RFC5023 section 8 [RFC5023], a Service Document is an 298 XML-based document format that allows a client to dynamically 299 discover the Collections provided by a publisher. A Service Document 300 consists of one or more app:workspace elements that may each contain 301 a number of app:collection elements. 303 The general structure of a service document is as follows (from 304 RFC5023 section 4.2 [RFC5023]): 306 Service 307 o- Workspace 308 | | 309 | o- Collection 310 | | | 311 | | o- IRI, categories, media types 312 | | 313 | o- ... 314 | 315 o- Workspace 316 | | 317 | o- Collection 318 | | | 319 | | o- IRI, categories, media types 320 | | 321 | o- ... 322 | 323 o- ... 325 5.1.1. Use of the "app:workspace" Element 327 In AtomPub, a Workspace, represented by the "app:workspace" element, 328 describes a group of one or more Collections. Building on the 329 AtomPub concept of a Workspace, in ROLIE a Workspace represents an 330 aggregation of Collections pertaining to security automation 331 information resources. This specification does not restrict the 332 number of Workspaces that may be in a Service Document or the 333 specific Collections to be provided within a given Workspace. 335 A ROLIE implementation can host Collections containing both public 336 and private information entries. It is suggested that 337 implementations segregate Collections into different app:workspace 338 elements by their client access requirements. With proper naming of 339 workspaces, this reduces the amount of trial and error a human user 340 would need to utilize to discover accessible Collections. 342 5.1.2. Use of the "app:collection" Element 344 In AtomPub, a Collection in a Service Document, represented by the 345 "app:collection" element, provides metadata that can be used to point 346 to a specific Atom Feed that contains information Entries that may be 347 of interest to a client. The association between a Collection and a 348 Feed is provided by the "href" attribute of the app:collection 349 element. Building on the AtomPub concept of a Collection, in ROLIE a 350 Collection represents a pointer to a group of security automation 351 information resources pertaining to a given type of security 352 automation information. Collections are represented as Atom Feeds as 353 per RFC 5023. Atom Feed specific requirements are defined in section 354 6.1. 356 ROLIE defines specialized data requirements for Collections, Feeds, 357 and Entries containing security automation related data. The 358 difference between a ROLIE and a non-ROLIE Collection defined in a 359 Service Document can be determined as follows: 361 ROLIE Collection: For an app:collection to be considered a ROLIE 362 Collection, the app:collection MUST contain an app:categories 363 element that contains only one atom:category element with the 364 "scheme" attribute value of 365 "urn:ietf:params:rolie:category:information-type". This category 366 MUST have an appropriate "term" attribute value as defined in 367 section 7.1.1. This ensures that a given Collection corresponds 368 to a specific type of security automation information. 370 Non-ROLIE Collection: For an app:collection to be considered a non- 371 ROLIE Collection, the app:collection MUST NOT contain an 372 atom:category element with a "scheme" attribute value of 373 "urn:ietf:params:rolie:category:information-type". 375 By distinguishing between ROLIE and non-ROLIE Collections in this 376 way, implementations supporting ROLIE can host Collections pertaining 377 to security automation information alongside Collections of other 378 non-ROLIE information within the same AtomPub instance. 380 The following are additional requirements on the use of the 381 app:collection element for a ROLIE Collection: 383 o The child atom:category elements contained in the app:categories 384 element MUST be the same set of atom:category elements used in the 385 Atom Feed resource referenced by the app:collection "href" 386 attribute value. This ensures that the category metadata 387 associated with the Collection and the associated Feed is 388 discoverable in both of these resources. 390 o The app:categories element in an app:collection MAY include 391 additional atom:category elements using a scheme other than 392 "urn:ietf:params:rolie:category:information-type". This allows 393 other category metadata to be included. 395 5.1.3. Service Document Discovery 397 ..his specification requires that an implementation MUST publish an 398 Atom Service Document that describes the set of security information 399 Collections provided by the service. The Service Document MUST be 400 retrievable using the standardized URI template 401 "https://{host:port}/.well-known/rolie/servicedocument", where 402 {host:port} is the authority portion of the URI. Dereferencing this 403 URI MAY result in a redirect based on an appropriate HTTP 3xx status 404 code to direct the client to the actual Service Document. This 405 allows clients to have a well-known location to find a ROLIE service 406 document, while giving implementations flexibility over how the 407 service is deployed. 409 This document registers the "rolie/servicedocument" well-known URI as 410 per [RFC5785] in Section 8.5. 412 A mechanism to determine which host and port to use is not specified 413 in this document. Use of a mechanism such as DNS SRV Records 414 [RFC2782] can provide a secure and reliable discovery mechanism for 415 determining a specific host and port to use for retrieving a Service 416 Document for a given DNS domain. 418 5.2. Category Documents 420 As described in RFC5023 section 7 [RFC5023], a Category Document is 421 an XML-based document format that allows a client to dynamically 422 discover the Categories used within AtomPub Service Documents, Atom 423 Syndication Feeds, and Entry documents provided by a publisher. A 424 Category Document consists of one app:categories element that 425 contains a number of inline atom:category elements, or a URI 426 referencing a Category Document. 428 5.3. Transport Layer Security 430 ROLIE is intended to be handled with TLS. TLS version 1.2 MUST be 431 supported. TLS 1.2 SHOULD be implemented according to all 432 recommendations and best practices present in [RFC7525]. 434 It is RECOMMENDED that the most recent published version of TLS is 435 supported. If this version is TLS 1.3 [I-D.ietf-tls-tls13], it is 436 recommended that 0-RTT (Zero Round Trip Time Resumption) is not used, 437 as there is a replay attack that is possible with that option. 439 The server MUST implement certificate-based client authentication. 440 This MAY be enabled on a workspace by workspace basis. 442 5.4. User Authentication and Authorization 444 Implementations MUST support user authentication. However, a given 445 implementation MAY allow user authentication to be disabled on a Feed 446 by Feed, or Workspace by Workspace basis. 448 Servers participating in an information sharing consortium and 449 supporting interactive user logins by members of the consortium 450 SHOULD support client authentication via a federated identity scheme. 452 This document does not mandate the use of any specific user 453 authorization mechanisms. However, service implementers SHOULD 454 support appropriate authorization checking for all resource accesses, 455 including individual Atom Entries, Atom Feeds, and Atom Service 456 Documents. 458 5.5. / (forward slash) Resource URL 460 The "/" resource MAY be supported for compatibility with existing 461 deployments that are using Transport of Real-time Inter-network 462 Defense (RID) Messages over HTTP/TLS [RFC6546]. 464 The following additional requirements only apply if a implementation 465 is supporting the "/" resource as described above: 467 o Consistent with RFC6546 errata, a client requesting a GET on the 468 "/" resource SHOULD receive an HTTP status code 405 Method Not 469 Allowed. 471 o An implementation MAY provide full support for [RFC6546] such that 472 a POST to the "/" resource containing a recognized RID message is 473 handled correctly as a RID request. Alternatively, a client 474 requesting a POST to "/" MAY receive an HTTP status code 307 475 Temporary Redirect. In this case, the location header in the HTTP 476 response will provide the URL of the appropriate RID endpoint, and 477 the client may repeat the POST method at the indicated location. 479 If the "/" resource is unsupported, then a request for this resource 480 MAY be handled as deemed appropriate by the server. 482 5.6. HTTP methods 484 Servers MAY accept request methods beyond those specified in this 485 document. 487 Clients MUST be capable of recognizing and processing any standard 488 HTTP status code, as defined in [RFC5023] Section 5. 490 6. ROLIE Requirements for the Atom Syndication Format 492 This section describes a number of restrictions of and extensions to 493 the Atom Syndication Format [RFC4287] that define the use of that 494 format in the context of a ROLIE-based solution. The normative 495 requirements in this section are generally oriented towards any 496 content to be published to a ROLIE server. An understanding of the 497 Atom Syndication Format specification [RFC4287] is helpful to 498 understand the requirements in this section. 500 6.1. Use of the "atom:feed" element 502 As described in RFC4287 section 4.1.1 [RFC4287], an Atom Feed is an 503 XML-based document format that describes a list of related 504 information items. The list of Atom Feeds provided by a ROLIE 505 service are listed in the service's Service Document through one or 506 more app:collection elements. Each Feed document, represented using 507 the atom:feed element, contains a listing of zero or more Entries. 509 When applied to the problem domain of security automation information 510 sharing, an Atom Feed may be used to represent any meaningful 511 collection of security automation information resources. Each Entry 512 in an atom:feed represents an individual resource (e.g., a specific 513 checklist, a software vulnerability record). Additional Feeds can be 514 used to represent other collections of security automation resources. 516 As discussed in section 5.1.2, ROLIE defines specialized data 517 requirements for Feeds containing security automation related data. 518 The difference between a ROLIE and a non-ROLIE Feed can be determined 519 as follows: 521 ROLIE Feed: For an atom:feed to be considered a ROLIE Feed, the 522 atom:feed MUST contain only one child atom:category element with 523 the "scheme" attribute value of 524 "urn:ietf:params:rolie:category:information-type". This category 525 MUST have an appropriate "term" attribute value as defined in 526 section 7.1.1. This ensures that a given Feed corresponds to a 527 specific type of security automation information. 529 Non-ROLIE Feed: For an atom:feed to be considered a non-ROLIE Feed, 530 the atom:feed MUST NOT contain an atom:category element with a 531 "scheme" attribute value of 532 "urn:ietf:params:rolie:category:information-type". 534 By distinguishing between ROLIE and non-ROLIE Feeds in this way, 535 implementations supporting ROLIE can host Feeds pertaining to 536 security automation information alongside Feeds of other non-ROLIE 537 information within the same AtomPub instance. This is parallel to 538 the handling of collections ealier in this specification in section 539 5.1.2. 541 The following Atom Feed definition represents a stricter definition 542 of the atom:feed element defined in RFC 4287 when used as a ROLIE 543 Feed. Any element not specified here inherits its definition and 544 requirements from [RFC4287]. 546 atomFeed = 547 element atom:feed { 548 atomCommonAttributes, 549 (atomAuthor* 550 & atomCategory+ 551 & atomContributor* 552 & atomGenerator? 553 & atomIcon? 554 & atomId 555 & atomLink+ 556 & atomLogo? 557 & atomRights? 558 & atomSubtitle? 559 & atomTitle 560 & atomUpdated 561 & extensionElement*), 562 atomEntry* 563 } 565 The following subsections contain requirements for a ROLIE Feed. 567 6.1.1. Use of the "atom:category" Element 569 An atom:feed can contain one or more atom:category elements. In Atom 570 the naming scheme and the semantic meaning of the terms used to 571 identify an Atom category are application-defined. 573 The following are additional requirements on the use of the 574 atom:category element when used in a ROLIE Feed: 576 o All member Entries in the Feed MUST represent security automation 577 information records of the provided information type category. 579 o An atom:feed MAY include additional atom:category elements using a 580 scheme other than "urn:ietf:params:rolie:category:information- 581 type". This allows other category metadata to be included. 583 6.1.2. Use of the "atom:link" Element 585 Link relations defined by the atom:link element are used to represent 586 state transitions using a stateless approach. In Atom a type of link 587 relationship can be defined using the "rel" attribute. 589 A ROLIE atom:feed MUST contain one or more atom:link elements with 590 rel="service" and href attribute whose value is a IRI that points to 591 an Atom Service Document associated with the atom:feed. If a client 592 accesses a Feed without first accessing the service's service 593 document, a link with the "service" relationship provides a means to 594 discover additional security automation information. The "service" 595 link relationship is defined in the IANA Link Relations Registry [1]. 597 An atom:feed can contain an arbitrary number of Entries. In some 598 cases, a complete Feed may consist of a large number of Entries. 599 Additionally, as new and updated Entries are ordered at the beginning 600 of a Feed, a client may only be interested in retrieving the first N 601 entries in a Feed to process only the Entries that have changed since 602 the last retrieval of the Feed. As a practical matter, a large set 603 of Entries will likely need to be divided into more manageable 604 portions, or pages. Based on RFC5005 section 3 [RFC5005], link 605 elements SHOULD be included in all Feeds to support paging using the 606 following link relation types: 608 o "first" - Indicates that the href attribute value of the link 609 identifies a resource IRI for the furthest preceding page of the 610 Feed. 612 o "last" - Indicates that the href attribute value of the link 613 identifies a resource IRI for the furthest following page of the 614 Feed. 616 o "previous" - Indicates that the href attribute value of the link 617 identifies a resource IRI for the immediately preceding page of 618 the Feed. 620 o "next" - Indicates that the href attribute value of the link 621 identifies a resource IRI for the immediately following page of 622 the Feed. 624 For example: 626 627 628 b7f65304-b63b-4246-88e2-c104049c5fd7 629 Paged Feed 630 631 632 633 634 635 2012-05-04T18:13:51.0Z 637 638 640 Example Paged Feed 642 A reference to a historical Feed may need to be stable, and/or a Feed 643 may need to be divided into a series of defined epochs. 644 Implementations SHOULD support the mechanisms described in RFC5005 645 section 4 [RFC5005] to provide link-based state transitions for 646 maintaining archiving of Feeds. 648 An atom:feed MAY include additional link relationships not specified 649 in this document. If a client encounters an unknown link 650 relationship type, the client MUST ignore the unrecognized link and 651 continue processing as if the unrecognized link element did not 652 appear. The definition of new Link relations that provide additional 653 state transition extensions is discussed in section 7.3. 655 6.1.3. Use of the "atom:updated" Element 657 The atom:updated element identifies the date and time that a Feed was 658 last updated. 660 The atom:updated element MUST be populated with the current time at 661 the instant the Feed was last updated by adding, updating, or 662 deleting an Entry; or changing any metadata for the Feed. 664 6.2. Use of the "atom:entry" Element 666 Each Entry in an Atom Feed, represented by the atom:entry element, 667 describes a single referenced information record, along with 668 descriptive information about its format, media type, and other 669 publication metadata. The following atom:entry schema definition 670 represents a stricter representation of the atom:entry element 671 defined in [RFC4287] for use in a ROLIE-based Atom Feed as defined in 672 section 6.1.1. 674 atomEntry = 675 element atom:entry { 676 atomCommonAttributes, 677 (atomAuthor* 678 & atomCategory* 679 & atomContent 680 & atomContributor* 681 & atomId 682 & atomLink* 683 & atomPublished? 684 & atomRights? 685 & atomSource? 686 & atomSummary? 687 & atomTitle 688 & atomUpdated 689 & rolieFormat 690 & rolieProperty* 691 & extensionElement*) 692 } 694 The notable changes from [RFC4287] are the addition of rolieFormat 695 and rolieProperty, and atomContent no longer being optional. 697 The following subsections contain requirements for Entries in a ROLIE 698 Feed. 700 6.2.1. Use of the "atom:content" Element 702 An atom:content element associates its containing Entry with a 703 content resource identified by the src attribute. 705 There MUST be exactly one atom:content element in the Entry. The 706 content element MUST adhere to this definition, which is a stricter 707 representation of the atom:content element defined in [RFC4287]: 709 atomContent = 710 element atom:content { 711 atomCommonAttributes, 712 attribute type { atomMediaType }, 713 attribute src { atomUri }, 714 empty 715 } 717 This restricts atomContent in ROLIE to the atomOutofLine forumulation 718 presented in[RFC4287]. 720 The type attribute MUST identify the serialization type of the 721 content, for example, application/xml or application/json. A 722 prefixed media type MAY be used to reflect a specific model used with 723 a given serialization approach (e.g., application/rdf+xml). The src 724 attribute MUST be an IRI that can be dereferenced to retrieve the 725 related content data. 727 6.2.2. Use of the "atom:link" Element 729 Link relations can be included in an atom:entry to represent state 730 transitions for the Entry. 732 If there is a need to provide the same information in different data 733 models and/or serialization formats, separate Entry instances can be 734 included in the same or a different Feed. Such an alternate content 735 representation can be indicated using an atom:link having a rel 736 attribute with the value "alternate". 738 An atom:feed MAY include additional link relationships not specified 739 in this document. If a client encounters an unknown link 740 relationship type, the client MUST ignore the unrecognized link and 741 continue processing as if the unrecognized link element did not 742 appear. The definition of new Link relations that provide additional 743 state transition extensions is discussed in section 7.3. 745 6.2.3. Use of the "rolie:format" Element 747 As mentioned earlier, a key goal of this specification is to allow a 748 consumer to review a set of published security automation information 749 resources, and then identify and retrieve any resources of interest. 750 The format of the data is a key criteria to consider when deciding 751 what information to retrieve. For a given type of security 752 automation information, it is expected that a number of different 753 formats may be used to represent this information. To support this 754 use case, both the serialization format and the specific data model 755 expressed in that format must be known by the consumer. 757 The rolie:format element is used to describe the data model used to 758 express the information referenced in the atom:content element of an 759 atom:entry. It also allows a schema to be identified that can be 760 used when parsing the content to verify or better understand the 761 structure of the content. 763 There MUST be exactly one rolie:format element in an atom:entry. The 764 element MUST adhere to this definition: 766 rolieFormat = 767 element rolie:format { 768 appCommonAttributes, 769 attribute ns { atomURI }, 770 attribute version { text } ?, 771 attribute schema-location { atomURI } ?, 772 attribute schema-type { atomMediaType } ?, 773 empty 774 } 776 The rolie:format element MUST provide a "ns" attribute that 777 identifies the data model of the resource referenced by the 778 atom:content element. For example, the namespace used may be an XML 779 namespace URI, or an identifier that represents a serialized JSON 780 model. The URI used for the "ns" attribute value MUST be an absolute 781 or opaque URI. The resource identified by the URI need not be 782 resolvable. 784 The rolie:format element MAY provide a "version" attribute that 785 identifies the version of the format used for the related 786 atom:content. 788 The rolie:format element MAY provide a "schema-location" attribute 789 that is a URI that identifies a schema resource that can be used to 790 validate the related atom:content. 792 The rolie:format element MAY provide a "schema-type" attribute, which 793 is a mime type identifying the format of the schema resource 794 identified by the "schema-location" attribute. 796 The following nominal example shows how these attributes describe the 797 format of the content: 799 805 The previous element provides an indication that the content of the 806 given entry is using the IODEF v2 format. 808 6.2.4. Use of the rolie:property Element 810 An atom:category element provides a way to associate a name/value 811 pair of categorical information using the scheme and term attributes 812 to represent the name, and the label attribute to represent the 813 value. When used in this way an atom:category allows a specific 814 label to be selected from a finite set of possible label values that 815 can be used to further classify a given atom:entry or atom:feed. 816 Within ROLIE, there may be a need to associate additional metadata 817 with an atom:entry. In such a case, use of an atom:category is not 818 practical to represent name/value data for which the allowed values 819 are unbounded. Instead, ROLIE has introduced a new rolie:property 820 element that can represent non-categorical metadata as name/value 821 pairs. Examples include content-specific identifiers, naming data, 822 and other properties that allow for unbounded values. 824 There MAY be zero or more rolie:property elements in an atom:entry. 826 The element MUST adhere to this definition: 828 rolieProperty = 829 element rolie:property { 830 app:appCommonAttributes, 831 attribute name { atom:atomURI }, 832 attribute value { text } 833 empty 834 } 836 The name attribute provides a URI that identifies the namespace and 837 name of the property as a URI. 839 The value attribute is text that provides a value for the property 840 identified by the name attribute. 842 For example, the nominal element 844 would expose an IODEF ID value contained in a given entry's content. 845 The name used in the example also demonstrates the use of a 846 registered ROLIE property extension, which is described in 847 Section 7.4. 849 Implementations MAY use locally defined and namespaced elements in an 850 Entry in order to provide additional information. Clients that do 851 not recognize a property with an unregistered name attribute MAY 852 ignore the rolie:property. 854 6.2.5. Requirements for a Standalone Entry 856 If an Entry is ever shared as a standalone resource, separate from 857 its containing Feed, then the following additional requirements 858 apply: 860 o The Entry MUST have an atom:link element with rel="collection" and 861 href="[IRI of the containing Collection]". This allows the Feed 862 or Feeds for which the Entry is a member to be discovered, along 863 with the related information the Feed may contain. In the case of 864 the Entry have multiple containing Feeds, the Entry MUST have one 865 atom:link for each related Feed. 867 o The Entry MUST declare the information type of the content 868 resource referenced by the Entry (see Section 7.1.2). 870 7. Available Extension Points Provided by ROLIE 872 This specification does not require particular information types or 873 data formats; rather, ROLIE is intended to be extended by additional 874 specifications that define the use of new categories and link 875 relations. The primary point of extension is through the definition 876 of new information type category terms. Additional specifications 877 can register new information type category terms with IANA that serve 878 as the main characterizing feature of a ROLIE Collection/Feed or 879 Resource/Entry. These additional specifications defining new 880 information type terms, can describe additional requirements for 881 including specific categories, link relations, as well as, use of 882 specific data formats supporting a given information type term. 884 7.1. The Category Extension Point 886 The atom:category element, defined in RFC 4287 section 4.2.2 887 [RFC4287], provides a mechanism to provide additional categorization 888 information for a content resource in ROLIE. The ability to define 889 new categories is one of the core extension points provided by Atom. 890 A Category Document, defined in RFC 5023 section 7 [RFC5023], 891 provides a mechanism for an Atom implementation to make discoverable 892 the atom:category terms and associated allowed values. 894 ROLIE further defines the use of the existing Atom extension category 895 mechanism by allowing ROLIE specific category extensions to be 896 registered with IANA, and additionally has assigned the 897 "urn:ietf:params:rolie:category:information-type" category scheme 898 that has special meaning for implementations of ROLIE. This allows 899 category scheme namespaces to be managed in a more consistent way, 900 allowing for greater interoperability between content producers and 901 consumers. 903 Any category whose "scheme" attribute uses an unregistered scheme 904 MUST be considered private use. Implementations encountering such a 905 category MUST parse the content without error, but MAY otherwise 906 ignore the element. 908 Use of the "atom:category" element is discussed in the following 909 subsections. 911 7.1.1. General Use of the "atom:category" Element 913 The atom:category element can be used for characterizing a ROLIE 914 Resource. As discussed earlier in this document, an atom:category 915 element has a "term" attribute that indicates the assigned category 916 value, and a "scheme" attribute that provides an identifier for the 917 category type. The "scheme" provides a means to describe how a set 918 of category terms should be used and provides a namespace that can be 919 used to differentiate terms provided by multiple organizations with 920 different semantic meaning. 922 To further differentiate category types used in ROLIE, an IANA sub- 923 registry has been established for ROLIE protocol parameters to 924 support the registration of new category "scheme" attribute values by 925 ROLIE extension specifications. Use of this extension point is 926 discussed in section 8.3 using the name field with a type parameter 927 of "category" to indicate a category extension. 929 7.1.2. Identification of Security Automation Information Types 931 A ROLIE specific extension point is provided through the 932 atom:category "scheme" value 933 "urn:ietf:params:rolie:category:information-type". This value is a 934 Uniform Resource Name (URN) [RFC8141] that is registered with IANA as 935 described in section 8.3. When used as the "scheme" attribute in 936 this way, the "term" attribute is expected to be a registered value 937 as defined in section Section 8.4. Through this mechanism a given 938 security automation information type can be used to: 940 1. identify that an "app:collection" element in a Service Document 941 points to an Atom Feed that contains Entries pertaining to a 942 specific type of security automation information (see section 943 5.1.2), or 945 2. identify that an "atom:feed" element in an Atom Feed contains 946 Entries pertaining to a specific type of security automation 947 information (see section 6.1.1). 949 3. identify the information type of a standalone Resource (see 950 section 6.2.5). 952 For example, the notional security automation information type 953 "incident" would be identified as follows: 955 959 A security automation information type represents a class of 960 information that represents the same or similar information model 961 [RFC3444]. Note that this document does not register any information 962 types, but offers the following as examples of potential information 963 types: 965 indicator: Computing device- or network-related "observable features 966 and phenomenon that aid in the forensic or proactive detection of 967 malicious activity; and associated meta-data" (from [RFC7970]). 969 incident: Information pertaining to and "derived analysis from 970 security incidents" (from [RFC7970]). 972 vulnerability reports: Information identifying and describing a 973 vulnerability in hardware or software. 975 configuration checklists: Content that can be used to assess the 976 configuration settings related to installed software. 978 software tags: Metadata used to identify and characterize 979 installable software. 981 This is a short list to inspire new engineering of information type 982 extensions that support the automation of security processes. 984 This document does not specify any information types. Instead, 985 information types in ROLIE are expected to be registered in extension 986 documents that describe one or more new information types. This 987 allows the information types used by ROLIE implementations to grow 988 over time to support new security automation use cases. These 989 extension documents may also enhance ROLIE Service, Category, Feed, 990 and Entry documents by defining link relations, other categories, and 991 Format data model extensions to address the representational needs of 992 these specific information types. New information types are added to 993 ROLIE through registrations to the IANA ROLIE Security Resource 994 Information Type registry defined in section 8.4. 996 7.2. The "rolie:format" Extension Point 998 Security automation data pertaining to a given information type may 999 be expressed using a number of supported formats. As described in 1000 section 6.2.3, the rolie:format element is used to describe the 1001 specific data model used to represent the resource referenced by a 1002 given "atom:entry". The structure provided by the rolie:format 1003 element, provides a mechanism for extension within the atom:entry 1004 model. ROLIE extensions MAY further restrict which data models are 1005 allowed to be used for a given information type. 1007 By declaring the data model used for a given Resource, a consumer can 1008 choose to download or ignore the Resource, or look for alternate 1009 formats. This saves the consumer from downloading and parsing 1010 resources that the consumer is not interested in or resources 1011 expressed in formats that are not supported by the consumer. 1013 7.3. The Link Relation Extension Point 1015 This document uses several link relations defined in the IANA Link 1016 Relation Types registry [2]. Additional link relations can be 1017 registered in this registry to allow new relationships to be 1018 represented in ROLIE according to RFC 4287 section 4.2.7.2 [RFC4287]. 1019 Based on the preceding reference, if the link relation is too 1020 specific or limited in the intended use, an absolute IRI can be used 1021 in lieu of registering a new simple name with IANA. 1023 7.4. The "rolie:property" Extension Point 1025 As discussed previously in Section 6.2.4, many formats contain unique 1026 identifying and characterizing properties that are vital for sharing 1027 information. In order to provide a global reference for these 1028 properties, this document establishes an IANA registry in Section 8.3 1029 that allows ROLIE extensions to register named properties using the 1030 name field with a type parameter of "property" to indicate a property 1031 extension. Implementations SHOULD prefer the use of registered 1032 properties over implementation specific properties when possible. 1034 ROLIE extensions are expected to register new and use existing 1035 properties to provide valuable identifying and characterizing 1036 information for a given information type and/or format. 1038 The namespace "urn:ietf:params:rolie:property:local" has been 1039 reserved in the IANA ROLIE Parameters table for private use as 1040 defined in [RFC8126]. Any property whose "name" attribute uses this 1041 as a prefix MUST be considered private use. Implementations 1042 encountering such a property MUST parse the content without error, 1043 but MAY otherwise ignore the element. 1045 This document also registers a number of general use properties that 1046 can be used to expose content information in any ROLIE use case. The 1047 following are descriptions of how to use these registered properties: 1049 urn:ietf:params:rolie:property:content-author-name The "value" 1050 attribute of this property is a text representation indicating the 1051 individual or organization that authored the content referenced by 1052 the "src" attribute of the entry's atom:content element. This 1053 author may differ from the atom:author when the author of the 1054 content and the entry are different people or entities. 1056 urn:ietf:params:rolie:property:content-id The "value" attribute of 1057 this property is a text representation of an identifier pertaining 1058 to or extracted from the content referenced by the "src" attribute 1059 of the entry's atom:content element. 1061 urn:ietf:params:rolie:property:content-published-date The "value" 1062 attribute of this property is a text representation indicating the 1063 original publication date of the content referenced by the "src" 1064 attribute of the entry's atom:content element. This date may 1065 differ from the published date of the ROLIE Entry because 1066 publication of the content and the ROLIE Entry represent different 1067 events. The date MUST be formatted as specified in [RFC3339]. 1069 urn:ietf:params:rolie:property:content-updated-date The "value" 1070 attribute of this property is a text representation indicating the 1071 date that the content, referenced by the "src" attribute of the 1072 entry's atom:content element, was last updated. This date may 1073 differ from the updated date of the ROLIE Entry because updates 1074 made to the content and to the ROLIE Entry are different events. 1075 The date MUST be formatted as specified in [RFC3339]. 1077 8. IANA Considerations 1079 This document has a number of IANA considerations described in the 1080 following subsections. 1082 8.1. XML Namespaces and Schema URNs 1084 This document uses URNs to describe XML namespaces and XML schemas 1085 conforming to a registry mechanism described in [RFC3688]. 1087 ROLIE XML Namespace The ROLIE namespace (rolie-1.0) has been 1088 registered in the "ns" registry. 1090 URI: urn:ietf:params:xml:ns:rolie-1.0 1092 Registrant Contact: IESG 1094 XML: None. Namespace URIs do not represent an XML specification. 1096 ROLIE XML Schema The ROLIE schema (rolie-1.0) has been registered in 1097 the "schema" registry. 1099 URI: urn:ietf:params:xml:schema:rolie-1.0 1101 Registrant Contact: IESG 1103 XML: See section A of this document. 1105 8.2. ROLIE URN Sub-namespace 1107 IANA has added an entry to the "IETF URN Sub-namespace for Registered 1108 Protocol Parameter Identifiers" registry located at 1109 as per 1110 RFC3553 [RFC3553]. 1112 The entry is as follows: 1114 Registry name: rolie 1116 Specification: This document 1118 Repository: ROLIE URN Parameters. See Section 8.3 [TO BE REMOVED: 1119 This registration should take place at the following location: 1120 https://www.iana.org/assignments/rolie] 1122 Index value: See Section 8.3 1124 8.3. ROLIE URN Parameters 1126 A new top-level registry has been created, entitled "Resource 1127 Oriented Lightweight Information Exchange (ROLIE) Parameters". [TO 1128 BE REMOVED: This registration should take place at the following 1129 location: https://www.iana.org/assignments/rolie] 1131 In this top-level registry, a sub-registry entitled "ROLIE URN 1132 Parameters" has been created. Registration in this repository is via 1133 the Specification Required policy [RFC8126]. Designated Expert 1134 reviews should be routed through the MILE WG mailing list. Failing 1135 this, the Designated Expert will be assigned by the IESG. 1137 Each entry in this sub-registry must record the following fields: 1139 Name: A URN segment that adheres to the pattern {type}:{label}. 1140 The keywords are defined as follows: 1142 {type}: The parameter type. The allowed values are "category" 1143 or "property". "category" denotes a category extension as 1144 discussed in Section 7.1. "property" denotes a property 1145 extension as discussed in Section 7.4. 1147 {label}: A required US-ASCII string that conforms to the URN 1148 syntax requirements (see [RFC8141]). This string must be 1149 unique within the namespace defined by the {type} keyword. The 1150 "local" label for both the "category" and "property" types has 1151 been reserved for private use. 1153 Extension IRI: The identifier to use within ROLIE, which is the 1154 full URN using the form: urn:ietf:params:rolie:{name}, where 1155 {name} is the "name" field of this registration. 1157 Reference: A static link to the specification and section that the 1158 definition of the parameter can be found. 1160 Sub-registry: An optional field that links to an IANA sub-registry 1161 for this parameter. If the {type} is "category", the sub-registry 1162 must contain a "name" field whose registered values MUST be US- 1163 ASCII. The list of names are the allowed values of the "term" 1164 attribute in the atom:category element. (See Section 7.1.2). 1166 This repository has the following initial values: 1168 +------------+--------------------+-------+-------------------------+ 1169 | Name | Extension IRI | Refer | Sub-Registry | 1170 | | | ence | | 1171 +------------+--------------------+-------+-------------------------+ 1172 | category:i | urn:ietf:params:ro | This | [TO BE REMOVED: This | 1173 | nformation | lie:category | docum | registration should | 1174 | -type | :information-type | ent, | take place at the | 1175 | | | Secti | following location: htt | 1176 | | | on | ps://www.iana.org/assig | 1177 | | | 8.4 | nments/rolie/category | 1178 | | | | /information-type] | 1179 | property:l | urn:ietf:params:ro | This | None | 1180 | ocal | lie:property:local | docum | | 1181 | | | ent, | | 1182 | | | Secti | | 1183 | | | on | | 1184 | | | 7.4 | | 1185 | property | urn:ietf:params:ro | This | None | 1186 | :content- | lie:property | docum | | 1187 | author- | :content-author- | ent, | | 1188 | name | name | Secti | | 1189 | | | on | | 1190 | | | 7.4 | | 1191 | property | urn:ietf:params:ro | This | None | 1192 | :content- | lie:property | docum | | 1193 | id | :content-id | ent, | | 1194 | | | Secti | | 1195 | | | on | | 1196 | | | 7.4 | | 1197 | property | urn:ietf:params:ro | This | None | 1198 | :content- | lie:property | docum | | 1199 | published- | :content- | ent, | | 1200 | date | published-date | Secti | | 1201 | | | on | | 1202 | | | 7.4 | | 1203 | property | urn:ietf:params:ro | This | None | 1204 | :content- | lie:property | docum | | 1205 | updated- | :content-updated- | ent, | | 1206 | date | date | Secti | | 1207 | | | on | | 1208 | | | 7.4 | | 1209 +------------+--------------------+-------+-------------------------+ 1211 8.4. ROLIE Security Resource Information Type Sub-Registry 1213 A new sub-registry has been created to store ROLIE information type 1214 values. 1216 Name of Registry: "ROLIE Information Types" 1218 Location of Registry: 1219 https://www.iana.org/assignments/rolie/category/information-type 1221 Fields to record in the registry: 1223 name: The full name of the security resource information type 1224 as a string from the printable ASCII character set [RFC0020] 1225 with individual embedded spaces allowed. This value must be 1226 unique in the context of this table. The ABNF [RFC5234] syntax 1227 for this field is: 1229 1*VCHAR *(SP 1*VCHAR) 1231 index: This is an IANA-assigned positive integer that 1232 identifies the registration. The first entry added to this 1233 registry uses the value 1, and this value is incremented for 1234 each subsequent entry added to the registry. 1236 reference: A list of one or more URIs [RFC3986] from which the 1237 registered specification can be obtained. The registered 1238 specification MUST be readily and publicly available from that 1239 URI. The URI SHOULD be a stable reference. 1241 Allocation Policy: Specification required as per [RFC8126] 1243 8.5. Well-Known URI Registrations 1245 This document makes the follow two registrations to the Well-Known 1246 URI Registry at https://www.iana.org/assignments/well-known-uris/ 1247 well-known-uris.xhtml. 1249 Service Document registration: 1251 URI suffix: rolie/servicedocument 1253 Change controller: IETF 1255 Specification document: This document, Section 5.1.3 1257 Related information: None 1259 9. Security Considerations 1261 This document defines a resource-oriented approach for lightweight 1262 information exchange using HTTP over TLS, the Atom Syndication 1263 Format, and the Atom Publishing Protocol. As such, implementers must 1264 understand the security considerations described in those 1265 specifications. All that follows is guidance, more specific 1266 instruction is out of scope for this document. 1268 To protect the confidentiality of a given resource provided by a 1269 ROLIE implementation, requests for retrieval of the resource need to 1270 be authenticated to prevent unauthorized users from accessing the 1271 resource (see section 5.4). It can also be useful to log and audit 1272 access to sensitive resources to verify that proper access controls 1273 remain in place over time. 1275 Access control to information published using ROLIE should use 1276 mechanisms that are appropriate to the sensitivity of the 1277 information. Primitive authentication mechanisms like HTTP Basic 1278 Authentication [RFC7617] are rarely appropriate for sensitive 1279 information. A number of authentication schemes are defined in the 1280 HTTP Authentication Schemes Registry [3]. Of these, HOBA [RFC7486] 1281 and SCRAM-SHA-256 [RFC7804] provide improved security properties over 1282 HTTP Basic [RFC7617]and Digest [RFC7616] Authentication Schemes. 1283 However, sharing communities that are engaged in sensitive 1284 collaborative analysis and/or operational response for indicators and 1285 incidents targeting high value information systems should adopt a 1286 suitably stronger user authentication solution, such as a risk-based 1287 or multi-factor approach. 1289 Collaborating consortiums may benefit from the adoption of a 1290 federated identity solution, such as those based upon OAuth [RFC6749] 1291 with JWT [RFC7797], or SAML-core [SAML-core], SAML-bind [SAML-bind], 1292 and SAML-prof [SAML-prof] for Web-based authentication and cross- 1293 organizational single sign-on. Dependency on a trusted third party 1294 identity provider implies that appropriate care must be exercised to 1295 sufficiently secure the Identity provider. Any attacks on the 1296 federated identity system would present a risk to the consortium, as 1297 a relying party. Potential mitigations include deployment of a 1298 federation-aware identity provider that is under the control of the 1299 information sharing consortium, with suitably stringent technical and 1300 management controls. 1302 Authorization of resource representations is the responsibility of 1303 the source system, i.e. based on the authenticated user identity 1304 associated with an HTTP(S) request. The required authorization 1305 policies that are to be enforced must therefore be managed by the 1306 security administrators of the source system. Various authorization 1307 architectures would be suitable for this purpose, such as RBAC [4] 1308 and/or ABAC, as embodied in XACML [XACML]. In particular, 1309 implementers adopting XACML may benefit from the capability to 1310 represent their authorization policies in a standardized, 1311 interoperable format. Note that implementers are free to choose any 1312 suitable authorization mechanism that is capable of fulfilling the 1313 policy enforcement requirements relevant to their consortium and/or 1314 organization. 1316 Additional security requirements such as enforcing message-level 1317 security at the destination system could supplement the security 1318 enforcements performed at the source system, however these 1319 destination-provided policy enforcements are out of scope for this 1320 specification. Implementers requiring this capability should 1321 consider leveraging, e.g. the element in the RID schema. 1322 Refer to RFC6545 section 9 for more information. Additionally, the 1323 underlying serialization approach used in the representation (e.g., 1324 XML, JSON) can offer encryption and message authentication 1325 capabilities. For example, XMLDSig [RFC3275] for XML, and JSON Web 1326 Encryption [RFC7516] and JSON Web Signature[RFC7515] for JSON can 1327 provide such mechanisms. 1329 When security policies relevant to the source system are to be 1330 enforced at both the source and destination systems, implementers 1331 must take care to avoid unintended interactions of the separately 1332 enforced policies. Potential risks will include unintended denial of 1333 service and/or unintended information leakage. These problems may be 1334 mitigated by avoiding any dependence upon enforcements performed at 1335 the destination system. When distributed enforcement is unavoidable, 1336 the usage of a standard language (e.g. XACML) for the expression of 1337 authorization policies will enable the source and destination systems 1338 to better coordinate and align their respective policy expressions. 1340 A service discovery mechanism is not explicitly specified in this 1341 document, and there are several approaches available for 1342 implementers. When selecting this mechanism, implementations need to 1343 ensure that their choice provides a means for authenticating the 1344 server. As described in the discovery section, DNS SRV Records are a 1345 possible solution to discovery. 1347 10. Privacy Considerations 1349 The optional author field may provide an identification privacy issue 1350 if populated without the author's consent. This information may 1351 become public if posted to a public feed. Special care should be 1352 taken when aggregating or sharing entries from other feeds, or when 1353 programmatically generating ROLIE entries from some data source that 1354 the author's personal info is not shared without their consent. 1356 When using the Atom Publishing Protocol to POST entries to a feed, 1357 attackers may use correlating techniques to profile the user. The 1358 request time can be compared to the generated "updated" field of the 1359 entry in order to build out information about a given user. This 1360 correlation attempt can be mitigated by not using HTTP requests to 1361 POST entries when profiling is a risk, and rather use backend control 1362 of the Feeds. 1364 Adoption of the information sharing approach described in this 1365 document will enable users to more easily perform correlations across 1366 separate, and potentially unrelated, cyber security information 1367 providers. A client may succeed in assembling a data set that would 1368 not have been permitted within the context of the authorization 1369 policies of either provider when considered individually. Thus, 1370 providers may face a risk of an attacker obtaining an access that 1371 constitutes an undetected separation of duties (SOD) violation. It 1372 is important to note that this risk is not unique to this 1373 specification, and a similar potential for abuse exists with any 1374 other cyber security information sharing protocol. However, the wide 1375 availability of tools for HTTP clients and Atom Feed handling implies 1376 that the resources and technical skills required for a successful 1377 exploit may be less than it was previously. This risk can be best 1378 mitigated through appropriate vetting of the client at account 1379 provisioning time. In addition, any increase in the risk of this 1380 type of abuse should be offset by the corresponding increase in 1381 effectiveness that this specification affords to the defenders. 1383 Overall, ROLIE introduces few privacy concerns above and beyond those 1384 present in any other HTTP protocol. Those that exist can be 1385 mitigated by following security considerations and carefully using 1386 the optional identifying elements. 1388 11. Acknowledgements 1390 The authors gratefully acknowledge the valuable contributions of Tom 1391 Maguire, Kathleen Moriarty, and Vijayanand Bharadwaj. These 1392 individuals provided detailed review comments on earlier drafts, and 1393 made many suggestions that have helped to improve this document. 1395 The authors would also like to thank the MILE Working Group, the SACM 1396 Working Group, and countless other people from both within the IETF 1397 community and outside of it for their excellent review and effort 1398 towards constructing this draft. 1400 12. References 1402 12.1. Normative References 1404 [relax-NG] 1405 Clark, J., Ed., "RELAX NG Compact Syntax", 11 2002, 1406 . 1409 [RFC0020] Cerf, V., "ASCII format for network interchange", STD 80, 1410 RFC 20, DOI 10.17487/RFC0020, October 1969, 1411 . 1413 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1414 Requirement Levels", BCP 14, RFC 2119, 1415 DOI 10.17487/RFC2119, March 1997, 1416 . 1418 [RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: 1419 Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, 1420 . 1422 [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An 1423 IETF URN Sub-namespace for Registered Protocol 1424 Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 1425 2003, . 1427 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1428 DOI 10.17487/RFC3688, January 2004, 1429 . 1431 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1432 Resource Identifier (URI): Generic Syntax", STD 66, 1433 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1434 . 1436 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1437 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 1438 December 2005, . 1440 [RFC4642] Murchison, K., Vinocur, J., and C. Newman, "Using 1441 Transport Layer Security (TLS) with Network News Transfer 1442 Protocol (NNTP)", RFC 4642, DOI 10.17487/RFC4642, October 1443 2006, . 1445 [RFC5005] Nottingham, M., "Feed Paging and Archiving", RFC 5005, 1446 DOI 10.17487/RFC5005, September 2007, 1447 . 1449 [RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., "The Atom 1450 Publishing Protocol", RFC 5023, DOI 10.17487/RFC5023, 1451 October 2007, . 1453 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1454 Housley, R., and W. Polk, "Internet X.509 Public Key 1455 Infrastructure Certificate and Certificate Revocation List 1456 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1457 . 1459 [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 1460 Uniform Resource Identifiers (URIs)", RFC 5785, 1461 DOI 10.17487/RFC5785, April 2010, 1462 . 1464 [RFC6546] Trammell, B., "Transport of Real-time Inter-network 1465 Defense (RID) Messages over HTTP/TLS", RFC 6546, 1466 DOI 10.17487/RFC6546, April 2012, 1467 . 1469 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1470 "Recommendations for Secure Use of Transport Layer 1471 Security (TLS) and Datagram Transport Layer Security 1472 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1473 2015, . 1475 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 1476 NETCONF Protocol over Transport Layer Security (TLS) with 1477 Mutual X.509 Authentication", RFC 7589, 1478 DOI 10.17487/RFC7589, June 2015, 1479 . 1481 [RFC7970] Danyliw, R., "The Incident Object Description Exchange 1482 Format Version 2", RFC 7970, DOI 10.17487/RFC7970, 1483 November 2016, . 1485 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1486 Writing an IANA Considerations Section in RFCs", BCP 26, 1487 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1488 . 1490 [W3C.REC-xml-names-20091208] 1491 Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 1492 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 1493 Wide Web Consortium Recommendation REC-xml-names-20091208, 1494 December 2009, 1495 . 1497 12.2. Informative References 1499 [I-D.ietf-tls-tls13] 1500 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1501 Version 1.3", draft-ietf-tls-tls13-21 (work in progress), 1502 July 2017. 1504 [REST] Fielding, R., "Architectural Styles and the Design of 1505 Network-based Software Architectures", 2000, 1506 . 1509 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1510 specifying the location of services (DNS SRV)", RFC 2782, 1511 DOI 10.17487/RFC2782, February 2000, 1512 . 1514 [RFC3275] Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible 1515 Markup Language) XML-Signature Syntax and Processing", 1516 RFC 3275, DOI 10.17487/RFC3275, March 2002, 1517 . 1519 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1520 Information Models and Data Models", RFC 3444, 1521 DOI 10.17487/RFC3444, January 2003, 1522 . 1524 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1525 Specifications: ABNF", STD 68, RFC 5234, 1526 DOI 10.17487/RFC5234, January 2008, 1527 . 1529 [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", 1530 RFC 6749, DOI 10.17487/RFC6749, October 2012, 1531 . 1533 [RFC7486] Farrell, S., Hoffman, P., and M. Thomas, "HTTP Origin- 1534 Bound Authentication (HOBA)", RFC 7486, 1535 DOI 10.17487/RFC7486, March 2015, 1536 . 1538 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 1539 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 1540 2015, . 1542 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 1543 RFC 7516, DOI 10.17487/RFC7516, May 2015, 1544 . 1546 [RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP 1547 Digest Access Authentication", RFC 7616, 1548 DOI 10.17487/RFC7616, September 2015, 1549 . 1551 [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", 1552 RFC 7617, DOI 10.17487/RFC7617, September 2015, 1553 . 1555 [RFC7797] Jones, M., "JSON Web Signature (JWS) Unencoded Payload 1556 Option", RFC 7797, DOI 10.17487/RFC7797, February 2016, 1557 . 1559 [RFC7804] Melnikov, A., "Salted Challenge Response HTTP 1560 Authentication Mechanism", RFC 7804, DOI 10.17487/RFC7804, 1561 March 2016, . 1563 [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 1564 (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, 1565 . 1567 [SAML-bind] 1568 Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. 1569 Maler, "Bindings for the OASIS Security Assertion Markup 1570 Language (SAML) V2.0", OASIS Standard saml-bindings- 1571 2.0-os, March 2005, . 1574 [SAML-core] 1575 Cantor, S., Kemp, J., Philpott, R., and E. Maler, 1576 "Assertions and Protocol for the OASIS Security Assertion 1577 Markup Language (SAML) V2.0", OASIS Standard saml-core- 1578 2.0-os, March 2005, . 1581 [SAML-prof] 1582 Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra, 1583 P., Philpott, R., and E. Maler, "Profiles for the OASIS 1584 Security Assertion Markup Language (SAML) V2.0", OASIS 1585 Standard OASIS.saml-profiles-2.0-os, March 2005, 1586 . 1589 [XACML] Rissanen, E., "eXtensible Access Control Markup Language 1590 (XACML) Version 3.0", August 2010, . 1593 12.3. URIs 1595 [1] https://www.iana.org/assignments/link-relations/link- 1596 relations.xhtml 1598 [2] https://www.iana.org/assignments/link-relations/link- 1599 relations.xhtml 1601 [3] https://www.iana.org/assignments/http-authschemes/http- 1602 authschemes.xhtml 1604 [4] http://csrc.nist.gov/groups/SNS/rbac/ 1606 Appendix A. Relax NG Compact Schema for ROLIE 1608 This appendix is informative. 1610 The Relax NG schema below defines the rolie:format element. 1612 # -*- rnc -*- 1613 # RELAX NG Compact Syntax Grammar for the rolie ns 1615 namespace rolie = "urn:ietf:params:xml:ns:rolie-1.0" 1616 namespace atom = "http://www.w3.org/2005/Atom" 1617 namespace app = "http://www.w3.org/2007/app" 1619 # rolie:format 1621 rolieFormat = 1622 element rolie:format { 1623 app:appCommonAttributes, 1624 attribute ns { atom:atomURI }, 1625 attribute version { text } ?, 1626 attribute schema-location { atom:atomURI } ?, 1627 attribute schema-type { atom:atomMediaType } ?, 1628 empty 1629 } 1631 # rolie:property 1633 rolieProperty = 1634 element rolie:property { 1635 app:appCommonAttributes, 1636 attribute name { atom:atomURI }, 1637 attribute value { text } 1638 empty 1639 } 1641 Appendix B. Examples of Use 1643 B.1. Service Discovery 1645 This section provides a non-normative example of a client doing 1646 service discovery. 1648 An Atom Service Document enables a client to dynamically discover 1649 what Feeds a particular publisher makes available. Thus, a provider 1650 uses an Atom Service Document to enable authorized clients to 1651 determine what specific information the provider makes available to 1652 the community. While the Service Document is accessible at a pre- 1653 determined location, the Service Document can also be made accessible 1654 from any well known location, such as via a link from the producer's 1655 home page. 1657 A client may format an HTTP GET request to retrieve the service 1658 document from the specified location: 1660 GET /.well-known/rolie/servicedocument 1661 Host: www.example.org 1662 Accept: application/atomsvc+xml 1664 Notice the use of the HTTP Accept: request header, indicating the 1665 MIME type for Atom service discovery. The response to this GET 1666 request will be an XML document that contains information on the 1667 specific Collections that are provided. 1669 Example HTTP GET response: 1671 HTTP/1.1 200 OK 1672 Date: Fri, 24 Aug 2016 17:09:11 GMT 1673 Content-Length: 570 1674 Content-Type: application/atomsvc+xml;charset="utf-8" 1676 1677 1679 1680 Vulnerabilities 1681 1682 Vulnerabilities Feed 1683 1684 1687 1688 1689 1690 1692 This simple Service Document example shows that the server provides 1693 one workspace, named "Vunerabilities". Within that workspace, the 1694 server makes one Collection available. 1696 A server may also offer a number of different Collections, each 1697 containing different types of security automation information. In 1698 the following example, a number of different Collections are 1699 provided, each with its own category and authorization scope. This 1700 categorization will help the clients to decide which Collections will 1701 meet their needs. 1703 HTTP/1.1 200 OK 1704 Date: Fri, 24 Aug 2016 17:10:11 GMT 1705 Content-Length: 1912 1706 Content-Type: application/atomsvc+xml;charset="utf-8" 1708 1709 1711 1712 Public Security Information Sharing 1713 1715 Public Vulnerabilities 1716 1718 1719 1722 1723 1724 1725 1726 Private Consortium Sharing 1727 1729 Incidents 1730 1732 1733 1736 1737 1738 1739 1741 In this example, the provider is making available a total of two 1742 Collections, organized into two different workspaces. The first 1743 workspace contains a Collection consisting of publicly available 1744 software vulnerabilities. The second workspace provides an incident 1745 Collection for use by a private sharing consortium. An appropriately 1746 authenticated and authorized client may then proceed to make HTTP 1747 requests for these Collections. The publicly provided vulnerability 1748 information may be accessible with or without authentication. 1749 However, users accessing the Collection restricted to authorized 1750 members of a private sharing consortium are expected to authenticate 1751 before access is allowed. 1753 B.2. Feed Retrieval 1755 This section provides a non-normative example of a client retrieving 1756 an vulnerability Feed. 1758 Having discovered the available security information sharing 1759 Collections, a client who is a member of the general public may be 1760 interested in receiving the Collection of public vulnerabilities. 1761 The client may retrieve the Feed for this Collection by performing an 1762 HTTP GET operation on the URL indicated by the Collection's "href" 1763 attribute. 1765 Example HTTP GET request for a Feed: 1767 GET /provider/public/vulns 1768 Host: www.example.org 1769 Accept: application/atom+xml 1771 The corresponding HTTP response would be an XML document containing 1772 the vulnerability Feed: 1774 Example HTTP GET response for a Feed: 1776 HTTP/1.1 200 OK 1777 Date: Fri, 24 Aug 2016 17:20:11 GMT 1778 Content-Length: 2882 1779 Content-Type: application/atom+xml;charset="utf-8" 1781 1782 1785 2a7e265a-39bc-43f2-b711-b8fd9264b5c9 1786 1787 Atom formatted representation of 1788 a feed of XML vulnerability documents 1789 1790 1793 2016-05-04T18:13:51.0Z 1794 1796 1798 1799 1800 dd786dba-88e6-440b-9158-b8fae67ef67c 1801 Sample Vulnerability 1802 2015-08-04T18:13:51.0Z 1803 2015-08-05T18:13:51.0Z 1804 A vulnerability issue identified by CVE-... 1805 1807 1809 1810 1811 1813 1815 This Feed document has two Atom Entries, one of which has been 1816 elided. The first Entry illustrates an atom:entry element that 1817 provides a summary of essential details about one particular 1818 vulnerability. Based upon this summary information and the provided 1819 category information, a client may choose to do an HTTP GET request, 1820 on the content "src" attribute, to retrieve the full details of the 1821 vulnerability. 1823 B.3. Entry Retrieval 1825 This section provides a non-normative example of a client retrieving 1826 an vulnerability as an Atom Entry. 1828 Having retrieved the Feed of interest, the client may then decide, 1829 based on the description and/or category information, that one of the 1830 entries in the Feed is of further interest. The client may retrieve 1831 this vulnerability Entry by performing an HTTP GET operation on the 1832 URL indicated by the "src" attribute of the atom:content element. 1834 Example HTTP GET request for an Entry: 1836 GET /provider/public/vulns/123456 1837 Host: www.example.org 1838 Accept: application/atom+xml;type=entry 1840 The corresponding HTTP response would be an XML document containing 1841 the Atom Entry for the vulnerability record: 1843 Example HTTP GET response for an Entry: 1845 HTTP/1.1 200 OK 1846 Date: Fri, 24 Aug 2016 17:30:11 GMT 1847 Content-Length: 713 1848 Content-Type: application/atom+xml;type=entry;charset="utf-8" 1850 1851 1854 f63aafa9-4082-48a3-9ce6-97a2d69d4a9b 1855 Sample Vulnerability 1856 2015-08-04T18:13:51.0Z 1857 2015-08-05T18:13:51.0Z 1858 1861 A vulnerability issue identified by CVE-... 1862 1863 1865 1866 1868 The example response above shows an XML document referenced by the 1869 "src" attribute of the atom:content element. The client may retrieve 1870 the document using this URL. 1872 Appendix C. Change History 1874 Changes in draft-ietf-mile-rolie-11 since draft-ietf-mile-rolie-09 1875 revision: 1877 Incorporated ART last call review and AD review changes 1879 Changes in draft-ietf-mile-rolie-09 since draft-ietf-mile-rolie-08 1880 revision: 1882 TLS requirements changed to clarify TLS versioning and 1883 recommendations 1885 Informative references and textual discussion added to Security 1886 Considerations around HTTP Authentication and content Signing/ 1887 Encryption. 1889 IANA Expert review clarified. 1891 Editorial changes from AD review/WGLC. 1893 Changes in draft-ietf-mile-rolie-08 since draft-ietf-mile-rolie-07 1894 revision: 1896 Reworked "usage of app:collection" and "usage of atom:feed" 1897 sections to clarify ROLIE vs non-ROLIE collections/feeds 1899 Removed requirement from Security Considerations that was a 1900 duplicate of text earlier in the document 1902 TLS requirement clarifications around mutal authentication 1904 Clarified requirements around support for the "/" resource 1906 Added IANA property registrations for content-id, content- 1907 published-date, and content-updated-date that can be used across 1908 all ROLIE extensions to increase consistency/interop 1910 Assorted editorial changes 1912 Changes in draft-ietf-mile-rolie-07 since draft-ietf-mile-rolie-06 1913 revision: 1915 Condensed and re-focused Sections 1 and 4 to be more concise. 1917 Added /.well-known/ registration and requirement for service 1918 discovery. 1920 Added local category, property namespace, and additional property 1921 registrations 1923 Added privacy considerations section. 1925 Made a number of editorial changes as per WGLC review. 1927 Changes in draft-ietf-mile-rolie-06 since draft-ietf-mile-rolie-05 1928 revision: 1930 Changed to standards track 1932 Added the rolie:property element 1934 Fixed references (Normative vs Informative) 1936 Set Service and Category document URL template requirements 1938 Fixed XML snippets in examples 1940 Changes in draft-ietf-mile-rolie-05 since draft-ietf-mile-rolie-04 1941 revision: 1943 Added ROLIE specific terminology to section 2 1945 Added AtomPub Category Document in section 5.2 1947 Edited document, improving consistency in terminology usage and 1948 capitalization of key terms, as well as enhancing clarity. 1950 Removed unused format parameter type in section 8.3 1952 Schema removed, the normative schema consists of the snippets in 1953 the requirements sections. 1955 Changes in draft-ietf-mile-rolie-04 since draft-ietf-mile-rolie-03 1956 revision: 1958 o Further specification and clarification of requirements 1960 o IANA Considerations and extension system fleshed out and 1961 described. 1963 o Examples and References updated. 1965 o Schema created. 1967 o Fixed both internal section and external document referencing. 1969 o Removed XACML Guidance Appendix. This will be added to a future 1970 draft on ROLIE Authentication and Access Control. 1972 Changes made in draft-ietf-mile-rolie-03 since draft-ietf-mile- 1973 rolie-02 revision: 1975 o Atom Syndication and Atom Pub requirements split and greatly 1976 expanded for increased justification and technical specification. 1978 o Reintroduction and reformatting of some use case examples in order 1979 to provide some guidance on use. 1981 o Established rough version of IANA table extension system along 1982 with explanations of said system. 1984 o Re-organized document to put non-vital information in appendices. 1986 Changes made in draft-ietf-mile-rolie-02 since draft-field-mile- 1987 rolie-01 revision: 1989 o All CSIRT and IODEF/RID material moved to companion CSIRT document 1991 o Recast document into a more general use perspective. The 1992 implication of CSIRTs as the defacto end-user has been removed 1993 where ever possible. All of the original CSIRT based use cases 1994 remain completely supported by this document, it has been opened 1995 up to support many other use cases. 1997 o Changed the content model to broaden support of representation 1999 o Edited and rewrote much of sections 1,2 and 3 in order to 2000 accomplish a broader scope and greater readability 2002 o Removed any requirements from the Background section and, if not 2003 already stated, placed them in the requirements section 2005 o Re-formatted the requirements section to make it clearer that it 2006 contains the lions-share of the requirements of the specification 2008 Changes made in draft-ietf-mile-rolie-01 since draft-field-mile- 2009 rolie-02 revision: 2011 o Added section specifying the use of RFC5005 for Archive and Paging 2012 of Feeds. 2014 o Added section describing use of atom categories that correspond to 2015 IODEF expectation class and impact classes. See: normative- 2016 expectation-impact 2018 o Dropped references to adoption of a MILE-specific HTTP media type 2019 parameter. 2021 o Updated IANA Considerations section to clarify that no IANA 2022 actions are required. 2024 Authors' Addresses 2026 John P. Field 2027 Pivotal Software, Inc. 2028 625 Avenue of the Americas 2029 New York, New York 2030 USA 2032 Phone: (646)792-5770 2033 Email: jfield@pivotal.io 2035 Stephen A. Banghart 2036 National Institute of Standards and Technology 2037 100 Bureau Drive 2038 Gaithersburg, Maryland 2039 USA 2041 Phone: (301)975-4288 2042 Email: stephen.banghart@nist.gov 2044 David Waltermire 2045 National Institute of Standards and Technology 2046 100 Bureau Drive 2047 Gaithersburg, Maryland 20877 2048 USA 2050 Email: david.waltermire@nist.gov