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/