RFC 8727 | JSON-IODEF | August 2020 |
Takahashi, et al. | Standards Track | [Page] |
- Stream:
- Internet Engineering Task Force (IETF)
- RFC:
- 8727
- Category:
- Standards Track
- Published:
- ISSN:
- 2070-1721
RFC 8727
JSON Binding of the Incident Object Description Exchange Format
Abstract
The Incident Object Description Exchange Format (IODEF) defined in RFC 7970 provides an information model and a corresponding XML data model for exchanging incident and indicator information. This document gives implementers and operators an alternative format to exchange the same information by defining an alternative data model implementation in JSON and its encoding in Concise Binary Object Representation (CBOR).¶
Status of This Memo
This is an Internet Standards Track document.¶
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.¶
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8727.¶
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶
1. Introduction
The Incident Object Description Exchange Format (IODEF) [RFC7970] 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 mitigation and watch-and-warning. An information model using Unified Modeling Language (UML) is defined in Section 3 of [RFC7970] and a corresponding Extensible Markup Language (XML) schema data model is defined in Section 8 of [RFC7970]. This UML-based information model and XML-based data model are referred to as IODEF UML and IODEF XML, respectively, in this 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 JavaScript Object Notation (JSON) [RFC8259]. To facilitate the automation of incident response operations, IODEF documents and implementations should support JSON representation and its encoding in Concise Binary Object Representation (CBOR) [RFC7049].¶
This document defines an alternate implementation of the IODEF UML information model by specifying a JSON data model using Concise Data Definition Language (CDDL) [RFC8610] and a JSON Schema [JSON-SCHEMA]. This JSON data model is referred to as IODEF JSON in this document. IODEF JSON provides all of the expressivity of IODEF XML. It gives implementers and operators an alternative format to exchange the same information.¶
The normative IODEF JSON data model is found in Section 6. Sections 2 and 3 describe the data types and elements of this data model. Section 4 provides examples.¶
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
2. IODEF Data Types
IODEF JSON implements the abstract data types specified in Section 2 of [RFC7970].¶
2.1. Abstract Data Type to JSON Data Type Mapping
IODEF JSON uses native and derived JSON data types. Table 1 describes the mapping between the abstract data types in Section 2 of [RFC7970] and their corresponding implementations in IODEF JSON.¶
IODEF Data Type | Reference | JSON Data Type |
---|---|---|
INTEGER | Section 2.1 of [RFC7970] | integer; see Section 2.2.1 |
REAL | Section 2.2 of [RFC7970] | "number" per [RFC8259] |
CHARACTER | Section 2.3 of [RFC7970] | "string" per [RFC8259] |
STRING | Section 2.3 of [RFC7970] | "string" per [RFC8259] |
ML_STRING | Section 2.4 of [RFC7970] | see Section 2.2.2 |
BYTE | Section 2.5.1 of [RFC7970] | "string" per [RFC8259] |
BYTE[] | Section 2.5.1 of [RFC7970] | "string" per [RFC8259] |
HEXBIN | Section 2.5.2 of [RFC7970] | "string" per [RFC8259] |
HEXBIN[] | Section 2.5.2 of [RFC7970] | "string" per [RFC8259] |
ENUM | Section 2.6 of [RFC7970] | see Section 2.2.3 |
DATETIME | Section 2.7 of [RFC7970] | "string" per [RFC8259] |
TIMEZONE | Section 2.8 of [RFC7970] | "string" per [RFC8259] |
PORTLIST | Section 2.9 of [RFC7970] | "string" per [RFC8259] |
POSTAL | Section 2.10 of [RFC7970] | ML_STRING; see Section 2.2.2 |
PHONE | Section 2.11 of [RFC7970] | "string" per [RFC8259] |
Section 2.12 of [RFC7970] | "string" per [RFC8259] | |
URL | Section 2.13 of [RFC7970] | "string" per [RFC8259] |
ID | Section 2.14 of [RFC7970] | "string" per [RFC8259] |
IDREF | Section 2.14 of [RFC7970] | "string" per [RFC8259] |
SOFTWARE | Section 2.15 of [RFC7970] | see Section 2.2.4 |
STRUCTUREDINFO | Section 4.4 of [RFC7203] | see Section 2.2.5 |
EXTENSION | Section 2.16 of [RFC7970] | see Section 2.2.6 |
IODEF Data Type | CBOR Data Type | CDDL Prelude [RFC8610] |
---|---|---|
INTEGER | 0, 1, 6 tag 2, 6 tag 3 | integer |
REAL | 7 bits 26 | float32 |
CHARACTER | 3 | text |
STRING | 3 | text |
ML_STRING | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
BYTE | 6 tag 22 | eb64legacy |
BYTE[] | 6 tag 22 | eb64legacy |
HEXBIN | 6 tag 23 | eb16 |
HEXBIN[] | 6 tag 23 | eb16 |
ENUM | - | Choices (Section 2.2.2 of [RFC8610]) |
DATETIME | 6 tag 0 | tdate |
TIMEZONE | 3 | text |
PORTLIST | 3 | text |
POSTAL | 3 | ML_STRING (Section 2.2.2) |
PHONE | 3 | text |
3 | text | |
URL | 6 tag 32 | uri |
ID | 3 | text |
IDREF | 3 | text |
SOFTWARE | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
STRUCTUREDINFO | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
EXTENSION | 5 | Maps/Structs (Section 3.5.1 of [RFC8610]) |
2.2. Complex JSON Types
2.2.1. Integer
An integer is a subset of the "number" type of JSON, which represents signed digits encoded in Base 10. The definition of this integer is "[ minus ] int" per [RFC8259], Section 6.¶
2.2.2. Multilingual Strings
A string that needs to be represented in a human-readable language different from the default encoding of the document is represented in the information model by the ML_STRING data type. This data type is implemented as either an object with "value", "lang", and "translation-id" elements or a text string as defined in Section 6. An example is shown below.¶
"MLStringType": { "value": "free-form text", # STRING "lang": "en", # ENUM "translation-id": "jp2en0023" # STRING }¶
Note that in figures throughout this document, some supplementary information follows "#", but these are not valid syntax in JSON; instead, they are intended to facilitate reader understanding.¶
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 model by the SOFTWARE data type. This software can be described by using a reference, a Uniform Resource Locator (URL) [RFC3986], or free-form text. The SOFTWARE data type is implemented as an object with "SoftwareReference", "URL", and "Description" elements as defined in Section 6. Examples are shown below.¶
"SoftwareType": { "SoftwareReference": {...}, # SoftwareReference "Description": ["MS Windows"] # STRING }¶
SoftwareReference class is a reference to a particular version of software. Examples are shown below.¶
"SoftwareReference": { "value": "cpe:/a:google:chrome:59.0.3071.115", # STRING "spec-name": "cpe", # ENUM "dtype": "string" # ENUM }¶
2.2.5. Structured Information
Information provided in the form of a structured string, such as an ID, or structured information, such as XML documents, is represented in the information model by the STRUCTUREDINFO data type. Note that this type was originally specified in Section 4.4 of [RFC7203] as a basic structure of its extension classes. The STRUCTUREDINFO data type is implemented as an object with "SpecID", "ext-SpecID", "ContentID", "RawData", and "Reference" elements. An example for embedding a structured ID is shown below.¶
"STRUCTUREDINFO": { "SpecID": "urn:ietf:params:xml:ns:mile:cwe:3.3", # ENUM "ContentID": "CWE-89" # STRING }¶
When embedding the raw data, it should be encoded as a BYTE type object, as shown below.¶
"STRUCTUREDINFO": { "SpecID": "urn:ietf:params:xml:ns:mile:mmdef:1.2", # ENUM "RawData": "<<< encoded structured data >>>" # BYTE }¶
When embedding the raw data, base64 encoding defined in Section 4 of [RFC4648] MUST be used for JSON IODEF while binary representation MUST be used for CBOR IODEF.¶
2.2.6. EXTENSION
Information not otherwise represented in the IODEF can be added using the EXTENSION data type. This data type is a generic extension mechanism. The EXTENSION data type is implemented as an ExtensionType object with "value", "name", "dtype", "ext-dtype", "meaning", "formatid", "restriction", "ext-restriction", and "observable-id" elements. An example for embedding a structured ID is shown below.¶
"ExtensionType": { "value": "xxxxxxx", # STRING "name": "Syslog", # STRING "dtype": "string", # ENUM "meaning": "Syslog from the security appliance X" # STRING }¶
Note that this data type is specified in [RFC7970] as its generic extension mechanism. If a data item has internal structure that is intended to be processed outside of the IODEF framework, one may consider using the STRUCTUREDINFO data type mentioned in Section 2.2.5.¶
3. IODEF JSON Data Model
3.1. Classes and Elements
The following table shows the list of IODEF classes and their elements and the corresponding sections in [RFC7970]. Note that the complete JSON schema is defined in Section 6 using CDDL.¶
IODEF Class | Class, Element, and Attribute | Section in [RFC7970] |
---|---|---|
IODEF-Document | 3.1 | |
Incident |
|
3.2 |
IncidentID | 3.4 | |
AlternativeID | 3.5 | |
RelatedActivity | 3.6 | |
ThreatActor | 3.7 | |
Campaign | 3.8 | |
Contact | 3.9 | |
RegistryHandle | 3.9.1 | |
PostalAddress | 3.9.2 | |
3.9.3 | ||
Telephone | 3.9.4 | |
Discovery | 3.10 | |
DetectionPattern | 3.10.1 | |
Method | 3.11 | |
Weakness | 4.5.5 in [RFC7203] | |
Reference | 3.11.1 | |
Assessment | 3.12 | |
SystemImpact | 3.12.1 | |
BusinessImpact | 3.12.2 | |
TimeImpact | 3.12.3 | |
MonetaryImpact | 3.12.4 | |
Confidence | 3.12.5 | |
History | 3.13 | |
HistoryItem | 3.13.1 | |
EventData | 3.14 | |
Expectation | 3.15 | |
System | 3.17 | |
Node | 3.18 | |
Address | 3.18.1 | |
NodeRole | 3.18.2 | |
Counter | 3.18.3 | |
DomainData | 3.19 | |
Nameservers | 3.19.1 | |
DomainContacts | 3.19.2 | |
Service | 3.20 | |
ServiceName | 3.20.1 | |
EmailData | 3.21 | |
RecordData | 3.22.1 | |
RecordPattern | 3.22.2 | |
WindowsRegistryKeysModified | 3.23 | |
Key | 3.23.1 | |
CertificateData | 3.24 | |
Certificate | 3.24.1 | |
FileData | 3.25 | |
File | 3.25.1 | |
HashData | 3.26 | |
Hash | 3.26.1 | |
FuzzyHash | 3.26.2 | |
Indicator | 3.29 | |
IndicatorID | 3.29.1 | |
AlternativeIndicatorID | 3.29.2 | |
Observable |
|
3.29.3 |
BulkObservable | 3.29.3.1 | |
BulkObservableFormat | 3.29.3.1.1 | |
IndicatorExpression | 3.29.4 | |
IndicatorReference | 3.29.7 | |
AttackPhase | 3.29.8 |
3.2. Mapping between JSON and XML IODEF
- Attributes and elements of each class in the XML IODEF document are both presented as JSON attributes in the JSON IODEF document, and the order of their appearances is ignored.¶
- Flow class is deleted, and classes with its instances now directly have instances of the EventData class that used to belong to the Flow class.¶
- ApplicationHeader class is deleted, and classes with its instances now directly have instances of the ApplicationHeaderField class that used to belong to the ApplicationHeader class.¶
- SignatureData class is deleted, and classes with its instances now directly have instances of the Signature class that used to belong to the SignatureData class.¶
- IndicatorData class is deleted, and classes with its instances now directly have instances of the Indicator class that used to belong to the IndicatorData class.¶
- ObservableReference class is deleted, and classes with its instances now directly have uid-ref as an element.¶
- Record class is deleted, and classes with its instances now directly have instances of the RecordData class that used to belong to the Record class.¶
- The MLStringType was modified to support simple string by allowing the type to have not only a predefined object type but also a text type, in order to allow simple descriptions of elements of the type. Implementations need to be capable of parsing an MLStringType that could take the form of both text and an object.¶
- The elements of the ML_STRING type in the XML IODEF document are presented as either STRING type or ML_STRING type in the JSON IODEF document. When converting from the XML IODEF document to the JSON IODEF document, or vice versa, the information contained in the original data of the ML_STRING type must be preserved. When STRING is used instead of ML_STRING, parsers can assume that its "xml:lang" is set to "en".¶
- Data models of the extension classes defined by [RFC7203] and referenced by [RFC7970] are represented by the STRUCTUREDINFO class defined in this document.¶
- Signature, X509Data, and RawData are encoded using base64 encoding for JSON IODEF and binary representation for CBOR IODEF to represent them as BYTE objects.¶
- EmailBody represents a whole message body including MIME structure in the same manner defined in [RFC7970]. In case of an email composed of a MIME multipart, the EmailBody contains multiple body parts separated by boundary strings.¶
- The "ipv6-net-mask" type attribute of the BulkObservable class remains available for the purpose of backward compatibility, but the use of this attribute is not recommended because IPv6 does not use netmask any more.¶
- ENUM values in this document are extensible and managed by IANA, which is also the case in [RFC7970]. The values in the table are used both by [RFC7970] implementations and by their JSON (and CBOR) bindings as specified by this document.¶
- This document uses JSON's "number" type to represent integers that only have full precision for integer values between -253 and 253. When dealing with integers outside the range, this issue needs to be considered.¶
- Binaries are encoded in bytes. Note that XML IODEF in [RFC7970] uses HEXBIN due to the incapability of XML for embedding binaries as they are.¶
4. Examples
This section provides examples of IODEF documents. These examples do not represent the full capabilities of the data model or the only way to encode particular information.¶
4.1. Minimal Example
A document containing only the mandatory elements and attributes is shown below in JSON and CBOR, respectively.¶
4.2. Indicators from a Campaign
An example of C2 domains from a given campaign is shown below in JSON and CBOR, respectively.¶
5. Mapkeys
The mapkeys are provided in Table 4 for minimizing the CBOR size.¶
mapkey | cborkey |
---|---|
iodef-version | -24 |
iodef-lang | -23 |
iodef-format-id | -22 |
iodef-private-enum-name | -21 |
iodef-private-enum-id | -20 |
iodef-Incident | -19 |
iodef-AdditionalData | -18 |
iodef-value | -17 |
iodef-translation-id | -16 |
iodef-name | -15 |
iodef-dtype | -14 |
iodef-ext-dtype | -13 |
iodef-meaning | -12 |
iodef-formatid | -11 |
iodef-restriction | -10 |
iodef-ext-restriction | -9 |
iodef-observable-id | -8 |
iodef-SoftwareReference | -7 |
iodef-URL | -6 |
iodef-Description | -5 |
iodef-spec-name | -4 |
iodef-ext-spec-name | -3 |
iodef-purpose | -2 |
iodef-ext-purpose | -1 |
iodef-status | 0 |
iodef-ext-status | 1 |
iodef-IncidentID | 2 |
iodef-AlternativeID | 3 |
iodef-RelatedActivity | 4 |
iodef-DetectTime | 5 |
iodef-StartTime | 6 |
iodef-EndTime | 7 |
iodef-RecoveryTime | 8 |
iodef-ReportTime | 9 |
iodef-GenerationTime | 10 |
iodef-Discovery | 11 |
iodef-Assessment | 12 |
iodef-Method | 13 |
iodef-Contact | 14 |
iodef-EventData | 15 |
iodef-Indicator | 16 |
iodef-History | 17 |
iodef-id | 18 |
iodef-instance | 19 |
iodef-ThreatActor | 20 |
iodef-Campaign | 21 |
iodef-IndicatorID | 22 |
iodef-Confidence | 23 |
iodef-ThreatActorID | 24 |
iodef-CampaignID | 25 |
iodef-role | 26 |
iodef-ext-role | 27 |
iodef-type | 28 |
iodef-ext-type | 29 |
iodef-ContactName | 30 |
iodef-ContactTitle | 31 |
iodef-RegistryHandle | 32 |
iodef-PostalAddress | 33 |
iodef-Email | 34 |
iodef-Telephone | 35 |
iodef-Timezone | 36 |
iodef-handle | 37 |
iodef-registry | 38 |
iodef-ext-registry | 39 |
iodef-PAddress | 40 |
iodef-EmailTo | 41 |
iodef-TelephoneNumber | 42 |
iodef-source | 43 |
iodef-ext-source | 44 |
iodef-DetectionPattern | 45 |
iodef-DetectionConfiguration | 46 |
iodef-Application | 47 |
iodef-Reference | 48 |
iodef-AttackPattern | 49 |
iodef-Vulnerability | 50 |
iodef-Weakness | 51 |
iodef-SpecID | 52 |
iodef-ext-SpecID | 53 |
iodef-ContentID | 54 |
iodef-RawData | 55 |
iodef-Platform | 56 |
iodef-Scoring | 57 |
iodef-ReferenceName | 58 |
iodef-specIndex | 59 |
iodef-ID | 60 |
iodef-occurrence | 61 |
iodef-IncidentCategory | 62 |
iodef-Impact | 63 |
iodef-SystemImpact | 64 |
iodef-BusinessImpact | 65 |
iodef-TimeImpact | 66 |
iodef-MonetaryImpact | 67 |
iodef-IntendedImpact | 68 |
iodef-Counter | 69 |
iodef-MitigatingFactor | 70 |
iodef-Cause | 71 |
iodef-severity | 72 |
iodef-completion | 73 |
iodef-ext-severity | 74 |
iodef-metric | 75 |
iodef-ext-metric | 76 |
iodef-duration | 77 |
iodef-ext-duration | 78 |
iodef-currency | 79 |
iodef-rating | 80 |
iodef-ext-rating | 81 |
iodef-HistoryItem | 82 |
iodef-action | 83 |
iodef-ext-action | 84 |
iodef-DateTime | 85 |
iodef-DefinedCOA | 86 |
iodef-System | 87 |
iodef-Expectation | 88 |
iodef-RecordData | 89 |
iodef-category | 90 |
iodef-ext-category | 91 |
iodef-interface | 92 |
iodef-spoofed | 93 |
iodef-virtual | 94 |
iodef-ownership | 95 |
iodef-ext-ownership | 96 |
iodef-Node | 97 |
iodef-NodeRole | 98 |
iodef-Service | 99 |
iodef-OperatingSystem | 100 |
iodef-AssetID | 101 |
iodef-DomainData | 102 |
iodef-Address | 103 |
iodef-Location | 104 |
iodef-vlan-name | 105 |
iodef-vlan-num | 106 |
iodef-unit | 107 |
iodef-ext-unit | 108 |
iodef-system-status | 109 |
iodef-ext-system-status | 110 |
iodef-domain-status | 111 |
iodef-ext-domain-status | 112 |
iodef-Name | 113 |
iodef-DateDomainWasChecked | 114 |
iodef-RegistrationDate | 115 |
iodef-ExpirationDate | 116 |
iodef-RelatedDNS | 117 |
iodef-NameServers | 118 |
iodef-DomainContacts | 119 |
iodef-Server | 120 |
iodef-SameDomainContact | 121 |
iodef-ip-protocol | 122 |
iodef-ServiceName | 123 |
iodef-Port | 124 |
iodef-Portlist | 125 |
iodef-ProtoCode | 126 |
iodef-ProtoType | 127 |
iodef-ProtoField | 128 |
iodef-ApplicationHeaderField | 129 |
iodef-EmailData | 130 |
iodef-IANAService | 131 |
iodef-EmailFrom | 132 |
iodef-EmailSubject | 133 |
iodef-EmailX-Mailer | 134 |
iodef-EmailHeaderField | 135 |
iodef-EmailHeaders | 136 |
iodef-EmailBody | 137 |
iodef-EmailMessage | 138 |
iodef-HashData | 139 |
iodef-Signature | 140 |
iodef-RecordPattern | 141 |
iodef-RecordItem | 142 |
iodef-FileData | 143 |
iodef-WindowsRegistryKeysModified | 144 |
iodef-CertificateData | 145 |
iodef-offset | 146 |
iodef-offsetunit | 147 |
iodef-ext-offsetunit | 148 |
iodef-Key | 149 |
iodef-registryaction | 150 |
iodef-ext-registryaction | 151 |
iodef-KeyName | 152 |
iodef-KeyValue | 153 |
iodef-Certificate | 154 |
iodef-X509Data | 155 |
iodef-File | 156 |
iodef-FileName | 157 |
iodef-FileSize | 158 |
iodef-FileType | 159 |
iodef-AssociatedSoftware | 160 |
iodef-FileProperties | 161 |
iodef-scope | 162 |
iodef-HashTargetID | 163 |
iodef-Hash | 164 |
iodef-FuzzyHash | 165 |
iodef-DigestMethod | 166 |
iodef-DigestValue | 167 |
iodef-CanonicalizationMethod | 168 |
iodef-FuzzyHashValue | 169 |
iodef-AlternativeIndicatorID | 170 |
iodef-Observable | 171 |
iodef-uid-ref | 172 |
iodef-IndicatorExpression | 173 |
iodef-IndicatorReference | 174 |
iodef-AttackPhase | 175 |
iodef-BulkObservable | 176 |
iodef-BulkObservableFormat | 177 |
iodef-BulkObservableList | 178 |
iodef-operator | 179 |
iodef-ext-operator | 180 |
iodef-euid-ref | 181 |
iodef-AttackPhaseID | 182 |
6. The IODEF Data Model (CDDL)
This section provides the IODEF data model. Note that mapkeys are described at the beginning of the CDDL data model for better readability.¶
7. IANA Considerations
This document has no IANA actions.¶
8. Security Considerations
This document provides a mapping from XML IODEF defined in [RFC7970] to JSON, and Section 3.2 describes several issues that arise when converting XML IODEF and JSON IODEF. Though it does not provide any further security considerations other than the one described in [RFC7970], implementers of this document should be aware of those issues to avoid any unintended outcome.¶
9. References
9.1. Normative References
- [RFC2119]
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/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, , <https://www.rfc-editor.org/info/rfc3986>.
- [RFC4648]
- Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, , <https://www.rfc-editor.org/info/rfc4648>.
- [RFC7049]
- Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, , <https://www.rfc-editor.org/info/rfc7049>.
- [RFC7203]
- Takahashi, T., Landfield, K., and Y. Kadobayashi, "An Incident Object Description Exchange Format (IODEF) Extension for Structured Cybersecurity Information", RFC 7203, DOI 10.17487/RFC7203, , <https://www.rfc-editor.org/info/rfc7203>.
- [RFC7970]
- Danyliw, R., "The Incident Object Description Exchange Format Version 2", RFC 7970, DOI 10.17487/RFC7970, , <https://www.rfc-editor.org/info/rfc7970>.
- [RFC8174]
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- [RFC8259]
- Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, , <https://www.rfc-editor.org/info/rfc8259>.
- [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, , <https://www.rfc-editor.org/info/rfc8610>.
9.2. Informative References
- [JSON-SCHEMA]
- Wright, A., Andrews, H., and B. Hutton, "JSON Schema Validation: A Vocabulary for Structural Validation of JSON", Work in Progress, Internet-Draft, draft-handrews-json-schema-validation-02, , <https://tools.ietf.org/html/draft-handrews-json-schema-validation-02>.
Appendix A. Data Types Used in This Document
The CDDL prelude used in this document is mapped to JSON as shown in the table below.¶
CDDL Prelude | Use of JSON | Instance | Validation |
---|---|---|---|
bytes | n/a | string | tool available |
text | string | string | unnecessary |
tdate | n/a | string | date-time per Section 7.3.1 of [JSON-SCHEMA] |
integer | n/a | number | integer |
eb64legacy | n/a | string | tool available |
uri | n/a | string | uri per Section 7.3.6 of [JSON-SCHEMA] |
float32 | float32 | number | unnecessary |
Appendix B. The IODEF Data Model (JSON Schema)
This section provides a JSON schema [JSON-SCHEMA] that defines the IODEF data model defined in this document. Note that this section is informative.¶
Acknowledgments
We would like to thank Henk Birkholz, Carsten Bormann, Benjamin Kaduk, Alexey Melnikov, Yasuaki Morita, and Takahiko Nagata for their insightful comments on this document and CDDL.¶