< draft-ietf-mile-jsoniodef-08.txt   draft-ietf-mile-jsoniodef-09.txt >
MILE T. Takahashi MILE T. Takahashi
Internet-Draft NICT Internet-Draft NICT
Intended status: Standards Track R. Danyliw Intended status: Standards Track R. Danyliw
Expires: October 3, 2019 CERT Expires: January 9, 2020 CERT
M. Suzuki M. Suzuki
NICT NICT
April 1, 2019 July 8, 2019
CBOR/JSON binding of IODEF CBOR/JSON binding of IODEF
draft-ietf-mile-jsoniodef-08 draft-ietf-mile-jsoniodef-09
Abstract Abstract
RFC7970 specified an information model and a corresponding XML data The Incident Object Description Exchange Format defined in RFC 7970
model for exchanging incident and indicator information. This draft provides an information model and a corresponding XML data model for
provides an alternative data model implementation in CBOR/JSON. exchanging incident and indicator information. This draft gives
implementers and operators an alternative format to exchange the same
information by defining an alternative data model implementation in
CBOR/JSON.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 October 3, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 3 2. IODEF Data Types . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Abstract Data Type to JSON Data Type Mapping . . . . . . 3 2.1. Abstract Data Type to JSON Data Type Mapping . . . . . . 3
2.2. Complex JSON Types . . . . . . . . . . . . . . . . . . . 5 2.2. Complex JSON Types . . . . . . . . . . . . . . . . . . . 5
2.2.1. Multilingual Strings . . . . . . . . . . . . . . . . 5 2.2.1. Integer . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2. Software and Software Reference . . . . . . . . . . . 6 2.2.2. Multilingual Strings . . . . . . . . . . . . . . . . 5
2.2.3. Structured Information . . . . . . . . . . . . . . . 6 2.2.3. Enum . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2.4. EXTENSION . . . . . . . . . . . . . . . . . . . . . . 7 2.2.4. Software and Software Reference . . . . . . . . . . . 6
2.2.5. Structured Information . . . . . . . . . . . . . . . 6
2.2.6. EXTENSION . . . . . . . . . . . . . . . . . . . . . . 7
3. IODEF JSON Data Model . . . . . . . . . . . . . . . . . . . . 7 3. IODEF JSON Data Model . . . . . . . . . . . . . . . . . . . . 7
3.1. Classes and Elements . . . . . . . . . . . . . . . . . . 7 3.1. Classes and Elements . . . . . . . . . . . . . . . . . . 7
3.2. Mapping between CBOR/JSON and XML IODEF . . . . . . . . . 17 3.2. Mapping between CBOR/JSON and XML IODEF . . . . . . . . . 17
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 18 4.1. Minimal Example . . . . . . . . . . . . . . . . . . . . . 18
4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 20 4.2. Indicators from a Campaign . . . . . . . . . . . . . . . 20
5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25 5. The IODEF Data Model (CDDL) . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
7. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
9.1. Normative References . . . . . . . . . . . . . . . . . . 40 9.1. Normative References . . . . . . . . . . . . . . . . . . 41
9.2. Informative References . . . . . . . . . . . . . . . . . 41 9.2. Informative References . . . . . . . . . . . . . . . . . 41
Appendix A. Data Types used in this document . . . . . . . . . . 41 Appendix A. Data Types used in this document . . . . . . . . . . 42
Appendix B. The IODEF Data Model (JSON Schema) . . . . . . . . . 41 Appendix B. The IODEF Data Model (JSON Schema) . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 70
1. Introduction 1. Introduction
[RFC7970] defines a data representation for security incident reports The Incident Object Description Exchange Format (IODEF) [RFC7970]
and indicators commonly exchanged by operational security teams. It defines a data representation for security incident reports and
indicators commonly exchanged by operational security teams. It
facilitates the automated exchange of this information to enable facilitates the automated exchange of this information to enable
mitigation and watch-and-warning. Section 3 of [RFC7970] defined an mitigation and watch-and-warning. Section 3 of [RFC7970] defined an
information model using Unified Modeling Language (UML) and a information model using Unified Modeling Language (UML) and a
corresponding Extensible Markup Language (XML) schema data model in corresponding Extensible Markup Language (XML) schema data model in
Section 8. This UML-based information model and XML-based data model Section 8. This UML-based information model and XML-based data model
are referred to as IODEF UML and IODEF XML, respectively in this are referred to as IODEF UML and IODEF XML, respectively in this
document. document.
IODEF documents are structured and thus suitable for machine
processing. They will streamline incident response operations.
Another well-used and structured format that is suitable for machine
processing is JSON. To facilitate the automation of incident
response operations, IODEF documents should support JSON
representation.
This document defines an alternate implementation of the IODEF UML This document defines an alternate implementation of the IODEF UML
information model by specifying a JavaScript Object Notation (JSON) information model by specifying a JavaScript Object Notation (JSON)
data model using CDDL and JSON Schema [jsonschema]. This JSON data data model using CDDL [RFC8610] and JSON Schema [jsonschema]. This
model is referred to as IODEF JSON in this document. JSON data model is referred to as IODEF JSON in this document. IODEF
JSON provides all of the expressivity of IODEF XML. It gives
IODEF JSON provides all of the expressivity of IODEF XML. It gives
implementers and operators an alternative format to exchange the same implementers and operators an alternative format to exchange the same
information. information.
The normative IODEF JSON data model is found in Section 5. Section 2 The normative IODEF JSON data model is found in Section 5. Section 2
and Section 3 describe the data types and elements of this data and Section 3 describe the data types and elements of this data
model. Section 4 provides examples. model. Section 4 provides examples.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 9 skipping to change at page 4, line 9
2.1. Abstract Data Type to JSON Data Type Mapping 2.1. Abstract Data Type to JSON Data Type Mapping
IODEF JSON uses native and derived JSON data types. Figure 1 IODEF JSON uses native and derived JSON data types. Figure 1
describes the mapping between the abstract data types in Section 2 of describes the mapping between the abstract data types in Section 2 of
[RFC7970] and their corresponding implementations in IODEF JSON. [RFC7970] and their corresponding implementations in IODEF JSON.
+-----------------+-------------------+-------------------------------+ +-----------------+-------------------+-------------------------------+
| IODEF Data Type | [RFC7970] | JSON Data Type | | IODEF Data Type | [RFC7970] | JSON Data Type |
| | Reference | | | | Reference | |
+-----------------+-------------------+-------------------------------+ +-----------------+-------------------+-------------------------------+
| INTEGER | Section 2.1 | "integer" per [jsonschema] | | INTEGER | Section 2.1 | integer, see Section 2.2.1 |
| REAL | Section 2.2 | "number" per [jsonschema] | | REAL | Section 2.2 | "number" per [RFC8259] |
| CHARACTER | Section 2.3 | "string" per [jsonschema] | | CHARACTER | Section 2.3 | "string" per [RFC8259] |
| STRING | Section 2.3 | "string" per [jsonschema] | | STRING | Section 2.3 | "string" per [RFC8259] |
| ML_STRING | Section 2.4 | see Section 2.2.1 | | ML_STRING | Section 2.4 | see Section 2.2.2 |
| BYTE | Section 2.5.1 | "string" per [jsonschema] | | BYTE | Section 2.5.1 | "string" per [RFC8259] |
| BYTE[] | Section 2.5.1 | "string" per [jsonschema] | | BYTE[] | Section 2.5.1 | "string" per [RFC8259] |
| HEXBIN | Section 2.5.2 | "string" per [jsonschema] | | HEXBIN | Section 2.5.2 | "string" per [RFC8259] |
| HEXBIN[] | Section 2.5.2 | "string" per [jsonschema] | | HEXBIN[] | Section 2.5.2 | "string" per [RFC8259] |
| ENUM | Section 2.6 | "enum" array per [jsonschema] | | ENUM | Section 2.6 | see Section 2.2.3 |
| DATETIME | Section 2.7 | "string" per [jsonschema] | | DATETIME | Section 2.7 | "string" per [RFC8259] |
| TIMEZONE | Section 2.8 | "string" per [jsonschema] | | TIMEZONE | Section 2.8 | "string" per [RFC8259] |
| PORTLIST | Section 2.9 | "string" per [jsonschema] | | PORTLIST | Section 2.9 | "string" per [RFC8259] |
| POSTAL | Section 2.10 | ML_STRING, Section 2.2.1 | | POSTAL | Section 2.10 | ML_STRING, Section 2.2.2 |
| PHONE | Section 2.11 | "string" per [jsonschema] | | PHONE | Section 2.11 | "string" per [RFC8259] |
| EMAIL | Section 2.12 | "string" per [jsonschema] | | EMAIL | Section 2.12 | "string" per [RFC8259] |
| URL | Section 2.13 | "string" per [jsonschema] | | URL | Section 2.13 | "string" per [RFC8259] |
| ID | Section 2.14 | "string" per [jsonschema] | | ID | Section 2.14 | "string" per [RFC8259] |
| IDREF | Section 2.14 | "string" per [jsonschema] | | IDREF | Section 2.14 | "string" per [RFC8259] |
| SOFTWARE | Section 2.15 | see Section 2.2.2 | | SOFTWARE | Section 2.15 | see Section 2.2.4 |
| STRUCTUREDINFO | [RFC 7203] | see Section 2.2.3 | | STRUCTUREDINFO | [RFC 7203] | see Section 2.2.5 |
| EXTENSION | Section 2.16 | see Section 2.2.4 | | EXTENSION | Section 2.16 | see Section 2.2.6 |
+-----------------+-------------------+-------------------------------+ +-----------------+-------------------+-------------------------------+
Figure 1: JSON Data Types Figure 1: JSON Data Types
+-----------------+------------------+---------------------------------+ +-----------------+------------------+---------------------------------+
| IODEF Data Type | CBOR Data Type | CDDL prelude | | IODEF Data Type | CBOR Data Type | CDDL prelude |
| | | [draft-ietf-cbor-cddl-05] | | | | [RFC8610] |
+-----------------+------------------+---------------------------------+ +-----------------+------------------+---------------------------------+
| INTEGER | 0, 1, 6 tag 2, | integer | | INTEGER | 0, 1, 6 tag 2, | integer |
| | 6 tag 3 | | | | 6 tag 3 | |
| REAL | 7 bits 26 | float32 | | REAL | 7 bits 26 | float32 |
| CHARACTER | 3 | text | | CHARACTER | 3 | text |
| STRING | 3 | text | | STRING | 3 | text |
| ML_STRING | 5 | Maps/Structs (Section 3.5.1) | | ML_STRING | 5 | Maps/Structs (Section 3.5.1) |
| BYTE | 6 tag 22 | eb64legacy | | BYTE | 6 tag 22 | eb64legacy |
| BYTE[] | 6 tag 22 | eb64legacy | | BYTE[] | 6 tag 22 | eb64legacy |
| HEXBIN | 2 | bytes | | HEXBIN | 2 | bytes |
skipping to change at page 5, line 38 skipping to change at page 5, line 38
| IDREF | 3 | text | | IDREF | 3 | text |
| SOFTWARE | 5 | Maps/Structs (Section 3.5.1) | | SOFTWARE | 5 | Maps/Structs (Section 3.5.1) |
| STRUCTUREDINFO | 5 | Maps/Structs (Section 3.5.1) | | STRUCTUREDINFO | 5 | Maps/Structs (Section 3.5.1) |
| EXTENSION | 5 | Maps/Structs (Section 3.5.1) | | EXTENSION | 5 | Maps/Structs (Section 3.5.1) |
+-----------------+------------------+---------------------------------+ +-----------------+------------------+---------------------------------+
Figure 2: CBOR Data Types Figure 2: CBOR Data Types
2.2. Complex JSON Types 2.2. Complex JSON Types
2.2.1. Multilingual Strings 2.2.1. Integer
An integer is a subset of "number" type of JSON, which represents
signed digits encoded in Base 10. The definition of this integer is
"[ minus ] int" in [RFC7159] Section 6 manner.
2.2.2. Multilingual Strings
A string that needs to be represented in a human-readable language A string that needs to be represented in a human-readable language
different from the default encoding of the document is represented in different from the default encoding of the document is represented in
the information model by the ML_STRING data type. This data type is the information model by the ML_STRING data type. This data type is
implemented as either an object with "value", "lang", and implemented as either an object with "value", "lang", and
"translation-id" elements or a text string as defined in Section 5. "translation-id" elements or a text string as defined in Section 5.
Examples are shown below. Examples are shown below.
"MLStringType": { "MLStringType": {
"value": "free-form text", //STRING "value": "free-form text", //STRING
"lang": "en", //ENUM "lang": "en", //ENUM
"translation-id": "jp2en0023" //STRING "translation-id": "jp2en0023" //STRING
} }
2.2.2. Software and Software Reference 2.2.3. Enum
Enum is an ordered list of acceptable string values. Each value has
a representative keyword. Within the data model, the enumerated type
keywords are used as attribute values.
2.2.4. Software and Software Reference
A particular version of software is represented in the information A particular version of software is represented in the information
model by the SOFTWARE data type. This software can be described by model by the SOFTWARE data type. This software can be described by
using a reference, a URL, or with free-form text. The SOFTWARE data using a reference, a Uniform Resource Locator (URL) [RFC3986], or
type is implemented as an object with "SoftwareReference", "URL", and with free-form text. The SOFTWARE data type is implemented as an
"Description" elements as defined in Section 5. Examples are shown object with "SoftwareReference", "URL", and "Description" elements as
below. defined in Section 5. Examples are shown below.
"SoftwareType": { "SoftwareType": {
"SoftwareReference": {...}, //SoftwareReference "SoftwareReference": {...}, //SoftwareReference
"Description": ["MS Windows"] //STRING "Description": ["MS Windows"] //STRING
} }
SoftwareReference class is a reference to a particular version of SoftwareReference class is a reference to a particular version of
software. Examples are shown below. software. Examples are shown below.
"SoftwareReference": { "SoftwareReference": {
"value": "cpe:/a:google:chrome:59.0.3071.115 ", //STRING "value": "cpe:/a:google:chrome:59.0.3071.115", //STRING
"spec-name": "cpe", //ENUM "spec-name": "cpe", //ENUM
"dtype": "string" //ENUM "dtype": "string" //ENUM
} }
2.2.3. Structured Information 2.2.5. Structured Information
Information provided in a form of structured string, such as ID, or Information provided in a form of structured string, such as ID, or
structured information, such as XML documents, is represented in the structured information, such as XML documents, is represented in the
information model by the STRUCTUREDINFO data type. Note that this information model by the STRUCTUREDINFO data type. Note that this
type was originally specified in [RFC7203]. The STRUCTUREDINFO data type was originally specified in [RFC7203]. The STRUCTUREDINFO data
type is implemented as an object with "SpecID", "ext-SpecID", type is implemented as an object with "SpecID", "ext-SpecID",
"ContentID", "dtype", "RawData", "Reference" elements. An example "ContentID", "RawData", "Reference" elements. An example for
for embedding a structured ID is shown below. embedding a structured ID is shown below.
"StructuredInfo": { "StructuredInfo": {
"SpecID": "cve", //ENUM "SpecID": "urn:ietf:params:xml:ns:mile:cwe:3.3", //ENUM
"ContentID": "CVE-2007-5000" //STRING "ContentID": "CWE-89" //STRING
} }
When embedding the raw data, base64 conversion should be used for When embedding the raw data, base64 encoding defined in Section 4 of
encoding the data, as shown below. [RFC4648] should be used for encoding the data, as shown below.
"StructuredInfo": { "StructuredInfo": {
"SpecID": "oval", //ENUM "SpecID": "urn:ietf:params:xml:ns:mile:mmdef:1.2", //ENUM
"RawData": "<<<strings encoded with base64>>>" //BYTE "RawData": "<<<strings encoded with base64>>>" //BYTE
} }
2.2.4. EXTENSION 2.2.6. EXTENSION
Information not otherwise represented in the IODEF can be added using Information not otherwise represented in the IODEF can be added using
the EXTENSION data type. This data type is a generic extension the EXTENSION data type. This data type is a generic extension
mechanism. The EXTENSION data type is implemented as an mechanism. The EXTENSION data type is implemented as an
ExtensionType object with "value", "name", "dtype", "ext-dtype", ExtensionType object with "value", "name", "dtype", "ext-dtype",
"meaning", "formatid", "restriction", "ext-restriction", and "meaning", "formatid", "restriction", "ext-restriction", and
"observable-id" elements. An example for embedding a structured ID "observable-id" elements. An example for embedding a structured ID
is shown below. is shown below.
"ExtensionType": { "ExtensionType": {
skipping to change at page 7, line 28 skipping to change at page 7, line 41
"dtype": "string", //ENUM "dtype": "string", //ENUM
"meaning": "Syslog from the security appliance X" //STRING "meaning": "Syslog from the security appliance X" //STRING
} }
3. IODEF JSON Data Model 3. IODEF JSON Data Model
3.1. Classes and Elements 3.1. Classes and Elements
The following table shows the list of IODEF Classes, their elements, The following table shows the list of IODEF Classes, their elements,
and the corresponding section in [RFC7970]. Note that the complete and the corresponding section in [RFC7970]. Note that the complete
JSON schema is defined in Section 5 usind CDDL. JSON schema is defined in Section 5 using CDDL.
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| IODEF Class | Class | Corresponding | | IODEF Class | Class | Corresponding |
| | Elements and | Section | | | Elements and | Section |
| | Attribute | in [RFC7970] | | | Attribute | in [RFC7970] |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
| IODEF-Document | version | 3.1 | | IODEF-Document | version | 3.1 |
| | lang? | | | | lang? | |
| | format-id? | | | | format-id? | |
| | private-enum-name? | | | | private-enum-name? | |
skipping to change at page 17, line 20 skipping to change at page 17, line 33
| | URL* | | | | URL* | |
| | Description* | | | | Description* | |
| | AdditionalData* | 3.29.8 | | | AdditionalData* | 3.29.8 |
+-----------------------------+--------------------+---------------+ +-----------------------------+--------------------+---------------+
Figure 3: IODEF Classes Figure 3: IODEF Classes
3.2. Mapping between CBOR/JSON and XML IODEF 3.2. Mapping between CBOR/JSON and XML IODEF
o This document treats attributes and elements of each class defined o This document treats attributes and elements of each class defined
in [RFC7970] equally and is agnostic on the order of their in [RFC7970] with no distinction and is agnostic on the order of
appearances. their appearances.
o Flow class is deleted, and classes with its instances now directly o Flow class is deleted, and classes with its instances now directly
have instances of EventData class that used to belong to the Flow have instances of EventData class that used to belong to the Flow
classs. class.
o ApplicationHeader class is deleted, and classes with its instances o ApplicationHeader class is deleted, and classes with its instances
now directly have instances of ApplicationHeaderField class that now directly have instances of ApplicationHeaderField class that
used to belong to the ApplicationHeader class. used to belong to the ApplicationHeader class.
o SignatureData class is deleted, and classes with its instances now o SignatureData class is deleted, and classes with its instances now
directly have instance of Signature class that used to belong to directly have instance of Signature class that used to belong to
the SignatureData class. the SignatureData class.
o IndicatorData class is deleted, and classes with its instances now o IndicatorData class is deleted, and classes with its instances now
skipping to change at page 18, line 16 skipping to change at page 18, line 29
o The elements of ML_STRING type in XML IODEF document are presented o The elements of ML_STRING type in XML IODEF document are presented
as either STRING type or ML_STRING type in CBOR/JSON IODEF as either STRING type or ML_STRING type in CBOR/JSON IODEF
document. document.
o Data models of the extension classes defined by [RFC7203] and o Data models of the extension classes defined by [RFC7203] and
referenced by [RFC7970] are represented by StructuredInfo class referenced by [RFC7970] are represented by StructuredInfo class
defined in this document. defined in this document.
o Signature, X509Data, and RawData are encoded with base64 and are o Signature, X509Data, and RawData are encoded with base64 and are
reprensetend as string (BYTE type) in CBOR/JSON IODEF documents. represented as string (BYTE type) in CBOR/JSON IODEF documents.
o EmailBody represents an whole message body including MIME
structure in the same manner defined in [RFC7970]. In case of an
email composed of MIME multipart, the EmailBody contains multiple
body parts separated by boundary strings.
4. Examples 4. Examples
This section provides examples of IODEF documents. These examples do This section provides examples of IODEF documents. These examples do
not represent the full capabilities of the data model or the only way not represent the full capabilities of the data model or the only way
to encode particular information. to encode particular information.
4.1. Minimal Example 4.1. Minimal Example
A document containing only the mandatory elements and attributes is A document containing only the mandatory elements and attributes is
skipping to change at page 20, line 19 skipping to change at page 20, line 41
67 # text(7) 67 # text(7)
456D61696C546F # "EmailTo" 456D61696C546F # "EmailTo"
78 19 # text(25) 78 19 # text(25)
636F6E746163744063736972742E6578616D706C652E636F6D 636F6E746163744063736972742E6578616D706C652E636F6D
# "contact@csirt.example.com" # "contact@csirt.example.com"
Figure 5: A Minimal Example in CBOR Figure 5: A Minimal Example in CBOR
4.2. Indicators from a Campaign 4.2. Indicators from a Campaign
An example of C2 domains from a given campaign is shwon below in JSON An example of C2 domains from a given campaign is shown below in JSON
and CBOR, respectively. and CBOR, respectively.
{ {
"version": "2.0", "version": "2.0",
"lang": "en", "lang": "en",
"Incident": [{ "Incident": [{
"purpose": "watch", "purpose": "watch",
"restriction": "green", "restriction": "green",
"IncidentID": { "IncidentID": {
"id": "897923", "id": "897923",
skipping to change at page 40, line 20 skipping to change at page 40, line 45
6. IANA Considerations 6. IANA Considerations
This document does not require any IANA actions. This document does not require any IANA actions.
7. Security Considerations 7. Security Considerations
This document does not provide any further security considerations This document does not provide any further security considerations
than the one described in [RFC7970]. than the one described in [RFC7970].
8. Acknowledgements 8. Acknowledgments
We would like to thank Henk Birkholz, Carsten Bormann, Yasuaki We would like to thank Henk Birkholz, Carsten Bormann, Yasuaki
Morita, and Takahiko Nagata for their insightful comments on CDDL. Morita, and Takahiko Nagata for their insightful comments on CDDL.
9. References 9. References
9.1. Normative References 9.1. Normative References
[cddlspec]
Henk Birkholz, Christoph Vigano, and Carsten Bormann,
"Concise data definition language (CDDL): a notational
convention to express CBOR and JSON data structuresy",
2018.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An [RFC7203] Takahashi, T., Landfield, K., and Y. Kadobayashi, "An
Incident Object Description Exchange Format (IODEF) Incident Object Description Exchange Format (IODEF)
Extension for Structured Cybersecurity Information", Extension for Structured Cybersecurity Information",
RFC 7203, DOI 10.17487/RFC7203, April 2014, RFC 7203, DOI 10.17487/RFC7203, April 2014,
<https://www.rfc-editor.org/info/rfc7203>. <https://www.rfc-editor.org/info/rfc7203>.
[RFC7970] Danyliw, R., "The Incident Object Description Exchange [RFC7970] Danyliw, R., "The Incident Object Description Exchange
Format Version 2", RFC 7970, DOI 10.17487/RFC7970, Format Version 2", RFC 7970, DOI 10.17487/RFC7970,
November 2016, <https://www.rfc-editor.org/info/rfc7970>. November 2016, <https://www.rfc-editor.org/info/rfc7970>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
9.2. Informative References 9.2. Informative References
[jsonschema] [jsonschema]
Francis Galiegue, Kris Zyp, and Gary Court, "JSON Schema: Francis Galiegue, Kris Zyp, and Gary Court, "JSON Schema:
core definitions and terminology", 2013. core definitions and terminology", 2013.
Appendix A. Data Types used in this document Appendix A. Data Types used in this document
The CDDL prelude used in this document is mapped to JSON as shown in The CDDL prelude used in this document is mapped to JSON as shown in
the table below. the table below.
skipping to change at page 41, line 37 skipping to change at page 42, line 27
| eb64legacy | n/a | string | tool available | | eb64legacy | n/a | string | tool available |
| uri | n/a | string | 7.3.6 uri | | uri | n/a | string | 7.3.6 uri |
| float32 | float32 | number | unnecessary | | float32 | float32 | number | unnecessary |
+-----------------+-------------------+----------------------------+ +-----------------+-------------------+----------------------------+
Figure 9: CDDL Prelude mapping in JSON Figure 9: CDDL Prelude mapping in JSON
Appendix B. The IODEF Data Model (JSON Schema) Appendix B. The IODEF Data Model (JSON Schema)
This section provides a JSON schema that defines the IODEF Data Model This section provides a JSON schema that defines the IODEF Data Model
defined in this draft. defined in this draft. Note that this section is Informative.
{ "$schema": "http://json-schema.org/draft-04/schema#", { "$schema": "http://json-schema.org/draft-04/schema#",
"definitions": { "definitions": {
"action": {"enum": ["nothing","contact-source-site", "action": {"enum": ["nothing","contact-source-site",
"contact-target-site","contact-sender","investigate", "contact-target-site","contact-sender","investigate",
"block-host","block-network","block-port","rate-limit-host", "block-host","block-network","block-port","rate-limit-host",
"rate-limit-network","rate-limit-port","redirect-traffic", "rate-limit-network","rate-limit-port","redirect-traffic",
"honeypot","upgrade-software","rebuild-asset","harden-asset", "honeypot","upgrade-software","rebuild-asset","harden-asset",
"remediate-other","status-triage","status-new-info", "remediate-other","status-triage","status-new-info",
"watch-and-report","training","defined-coa","other", "watch-and-report","training","defined-coa","other",
 End of changes. 33 change blocks. 
76 lines changed or deleted 114 lines changed or added

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