RFC Errata
Found 14 records.
Status: Verified (6)
RFC 7970, "The Incident Object Description Exchange Format Version 2", November 2016
Source of RFC: mile (sec)
Errata ID: 5351
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2018-05-07
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20
Section 2.16 says:
The attributes of the iodef:ExtensionType type are:
name
Optional. STRING. A free-form name of the field or data element.
dtype
Required. ENUM. The data type of the element content. The
default value is "string". These values are maintained in the
"ExtensionType-dtype" IANA registry per Section 10.2.
1. boolean. The element content is of type BOOLEAN.
2. byte. The element content is of type BYTE.
3. bytes. The element content is of type HEXBIN.
4. character. The element content is of type CHARACTER.
5. date-time. The element content is of type DATETIME.
6. ntpstamp. Same as date-time.
7. integer. The element content is of type INTEGER.
8. portlist. The element content is of type PORTLIST.
9. real. The element content is of type REAL.
10. string. The element content is of type STRING.
11. file. The element content is a base64-encoded binary file
encoded as a BYTE[] type.
12. path. The element content is a file-system path encoded as a
STRING type.
13. frame. The element content is a Layer 2 frame encoded as a
HEXBIN type.
14. packet. The element content is a Layer 3 packet encoded as a
HEXBIN type.
15. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN type.
16. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN type.
17. url. The element content is of type URL.
18. csv. The element content is a comma-separated value (CSV)
list per Section 2 of [RFC4180] encoded as a STRING type.
19. winreg. The element content is a Microsoft Windows registry
key encoded as a STRING type.
20. xml. The element content is XML. See Section 5.2.
21. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1.
It should say:
The attributes of the iodef:ExtensionType type are:
name
Optional. STRING. A free-form name of the field or data element.
dtype
Required. ENUM. The data type of the element content. The
default value is "string". These values are maintained in the
"ExtensionType-dtype" IANA registry per Section 10.2.
1. boolean. The element content is of type BOOLEAN.
2. byte. The element content is of type BYTE.
3. bytes. The element content is of type HEXBIN[].
4. character. The element content is of type CHARACTER.
5. date-time. The element content is of type DATETIME.
6. ntpstamp. Same as date-time.
7. integer. The element content is of type INTEGER.
8. portlist. The element content is of type PORTLIST.
9. real. The element content is of type REAL.
10. string. The element content is of type STRING.
11. file. The element content is a base64-encoded binary file
encoded as a BYTE[] type.
12. path. The element content is a file-system path encoded as a
STRING type.
13. frame. The element content is a Layer 2 frame encoded as a
HEXBIN[] type.
14. packet. The element content is a Layer 3 packet encoded as a
HEXBIN[] type.
15. ipv4-packet. The element content is an IPv4 packet encoded
as a HEXBIN[] type.
16. ipv6-packet. The element content is an IPv6 packet encoded
as a HEXBIN[] type.
17. url. The element content is of type URL.
18. csv. The element content is a comma-separated value (CSV)
list per Section 2 of [RFC4180] encoded as a STRING type.
19. winreg. The element content is a Microsoft Windows registry
key encoded as a STRING type.
20. xml. The element content is XML. See Section 5.2.
21. ext-value. A value used to indicate that this attribute is
extended and the actual value is provided using the
corresponding ext-* attribute. See Section 5.1.1.
Notes:
Section 2.5.2 (explanation of HEXBIN and HEXBIN[] types) says:
" A binary octet encoded as a character tuple consistent of two
hexadecimal digits is represented in the information model by the
HEXBIN data type. A sequence of these octets is of the HEXBIN[] data
type.
The HEXBIN and HEXBIN[] data types are implemented in the data model
as an "xs:hexBinary" type per Section 3.2.15 of [W3C.SCHEMA.DTYPES]."
If I am reading that section correctly, HEXBIN is for hex-encoded things that decode to exactly one byte, while HEXBIN[] is for hex-encoded things that decode to one or more bytes. Thus, things that may decode to multiple bytes should be HEXBIN[], not HEXBIN.
The extension types in Section 2.16 that are currently HEXBIN should probably be HEXBIN[]. The name "bytes" implies decoding to multiple bytes (so it should be HEXBIN[]). Frames and packets (regardless of layer) tend to be multiple bytes long (so they should be HEXBIN[] as well).
Errata ID: 5543
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-11-04
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05
Section 8 says:
<xs:element name="Confidence">
<xs:complexType>
<xs:attribute name="rating"
type="confidence-rating-type" use="required"/>
<xs:attribute name="ext-rating"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
It should say:
<xs:element name="Confidence">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:float">
<xs:attribute name="rating"
type="confidence-rating-type" use="required"/>
<xs:attribute name="ext-rating"
type="xs:string" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
Notes:
Section 3.12.5 says as follows:
"The content of the class is of type REAL and specifies a numerical
assessment in the confidence of the data when the value of the rating
attribute is "numeric". Otherwise, this element MUST be empty."
The current schema does not allow the confidence class to have the content (REAL type), thus the correction (note the addition of "<xs:extension base="xs:float">") is proposed.
Errata ID: 5544
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-11-04
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05
Section 8 says:
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:DomainData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
<xs:element ref="iodef:Location"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
It should say:
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:DomainData"
maxOccurs="unbounded"/>
<xs:element ref="iodef:Address"
maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
<xs:element ref="iodef:Location"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Notes:
Section 3.18 says as follows:
"DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.
Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1."
To comply with the above definition, "minOccurs" attribute for both DomainData and Address elements need to be removed. (Current schema allows to omit both of the elements, but the RFC says that at least one of them need to be presented.)
Errata ID: 5583
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-12-25
Verifier Name: Roman Danyliw
Date Verified: 2022-01-20
Section 8 says:
<xs:simpleType name="action-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="nothing"/>
<xs:enumeration value="contact-source-site"/>
<xs:enumeration value="contact-target-site"/>
<xs:enumeration value="contact-sender"/>
<xs:enumeration value="investigate"/>
<xs:enumeration value="block-host"/>
<xs:enumeration value="block-network"/>
<xs:enumeration value="block-port"/>
<xs:enumeration value="rate-limit-host"/>
<xs:enumeration value="rate-limit-network"/>
<xs:enumeration value="rate-limit-port"/>
<xs:enumeration value="redirect-traffic"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="upgrade-software"/>
<xs:enumeration value="rebuild-asset"/>
<xs:enumeration value="harden-asset"/>
<xs:enumeration value="remediate-other"/>
<xs:enumeration value="status-triage"/>
<xs:enumeration value="status-new-info"/>
<xs:enumeration value="watch-and-report"/>
<xs:enumeration value="defined-coa"/>
It should say:
<xs:simpleType name="action-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="nothing"/>
<xs:enumeration value="contact-source-site"/>
<xs:enumeration value="contact-target-site"/>
<xs:enumeration value="contact-sender"/>
<xs:enumeration value="investigate"/>
<xs:enumeration value="block-host"/>
<xs:enumeration value="block-network"/>
<xs:enumeration value="block-port"/>
<xs:enumeration value="rate-limit-host"/>
<xs:enumeration value="rate-limit-network"/>
<xs:enumeration value="rate-limit-port"/>
<xs:enumeration value="redirect-traffic"/>
<xs:enumeration value="honeypot"/>
<xs:enumeration value="upgrade-software"/>
<xs:enumeration value="rebuild-asset"/>
<xs:enumeration value="harden-asset"/>
<xs:enumeration value="remediate-other"/>
<xs:enumeration value="status-triage"/>
<xs:enumeration value="status-new-info"/>
<xs:enumeration value="watch-and-report"/>
<xs:enumeration value="training"/>
<xs:enumeration value="defined-coa"/>
Notes:
The narrative text in Section 3.1.5 defined an enumerated value of "training" for the action attribute, but the schema omitted it.
Errata ID: 5422
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05
Section 8 says:
<xs:simpleType name="bulkobservable-type-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/>
<xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/>
<xs:enumeration value="mac"/>
<xs:enumeration value="site-uri"/>
<xs:enumeration value="domain-name"/>
<xs:enumeration value="domain-to-ipv4"/>
<xs:enumeration value="domain-to-ipv6"/>
<xs:enumeration value="domain-to-ipv4-timestamp"/>
<xs:enumeration value="domain-to-ipv6-timestamp"/>
<xs:enumeration value="ipv4-port"/>
<xs:enumeration value="ipv6-port"/>
<xs:enumeration value="windows-reg-key"/>
<xs:enumeration value="file-hash"/>
<xs:enumeration value="email-x-mailer"/>
<xs:enumeration value="email-subject"/>
<xs:enumeration value="http-user-agent"/>
<xs:enumeration value="http-request-uri"/>
<xs:enumeration value="mutex"/>
<xs:enumeration value="file-path"/>
<xs:enumeration value="user-name"/>
</xs:restriction>
</xs:simpleType>
It should say:
<xs:simpleType name="bulkobservable-type-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="asn"/>
<xs:enumeration value="atm"/>
<xs:enumeration value="e-mail"/>
<xs:enumeration value="ipv4-addr"/>
<xs:enumeration value="ipv4-net"/>
<xs:enumeration value="ipv4-net-mask"/>
<xs:enumeration value="ipv6-addr"/>
<xs:enumeration value="ipv6-net"/>
<xs:enumeration value="ipv6-net-mask"/>
<xs:enumeration value="mac"/>
<xs:enumeration value="site-uri"/>
<xs:enumeration value="domain-name"/>
<xs:enumeration value="domain-to-ipv4"/>
<xs:enumeration value="domain-to-ipv6"/>
<xs:enumeration value="domain-to-ipv4-timestamp"/>
<xs:enumeration value="domain-to-ipv6-timestamp"/>
<xs:enumeration value="ipv4-port"/>
<xs:enumeration value="ipv6-port"/>
<xs:enumeration value="windows-reg-key"/>
<xs:enumeration value="file-hash"/>
<xs:enumeration value="email-x-mailer"/>
<xs:enumeration value="email-subject"/>
<xs:enumeration value="http-user-agent"/>
<xs:enumeration value="http-request-uri"/>
<xs:enumeration value="mutex"/>
<xs:enumeration value="file-path"/>
<xs:enumeration value="user-name"/>
<xs:enumeration value="ext-value"/>
</xs:restriction>
</xs:simpleType>
Notes:
The main body text says that the enum values of the type attribute of bulkobservable class include “ext-value”. The schema was not consistentent with the body text, thus corrected.
Errata ID: 5423
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-07-15
Verifier Name: Alexey Melnikov
Date Verified: 2018-11-05
Section 8 says:
<xs:element name="ThreatActor">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ThreatActorID"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:URL" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" use="optional"/>
<xs:attribute name="ext-restriction"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
It should say:
<xs:element name="ThreatActor">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:ThreatActorID"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:URL"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Description"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:AdditionalData"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" use="optional"/>
<xs:attribute name="ext-restriction"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
Notes:
The number of URL occurance could be zero, according to the main body text.
The minOccurs of the URL in the TreatActorclass was defined.
(The default value of minOccurs is one, not zero.)
Status: Reported (8)
RFC 7970, "The Incident Object Description Exchange Format Version 2", November 2016
Source of RFC: mile (sec)
Errata ID: 5398
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2018-06-19
Section 3.29.2 says:
The AlternativeIndicatorID class lists alternative identifiers for an
indicator.
+-------------------------+
| AlternativeIndicatorID |
+-------------------------+
| ENUM restriction |<>--{1..*}--[ IndicatorReference ]
| STRING ext-restriction |
+-------------------------+
Figure 61: The AlternativeIndicatorID Class
The aggregate class of the AlternativeIndicatorID class is:
IndicatorReference
One or more. A reference to an indicator. See Section 3.29.7.
The attributes of the AlternativeIndicatorID class are:
restriction
Optional. ENUM. See Section 3.3.1.
ext-restriction
Optional. STRING. A means by which to extend the restriction
attribute. See Section 5.1.1.
It should say:
The AlternativeIndicatorID class lists alternative identifiers for an
indicator.
+-------------------------+
| AlternativeIndicatorID |
+-------------------------+
| ENUM restriction |<>--{1..*}--[ IndicatorID ]
| STRING ext-restriction |
+-------------------------+
Figure 61: The AlternativeIndicatorID Class
The aggregate class of the AlternativeIndicatorID class is:
IndicatorID
One or more. An alternative ID for the indicator.
See Section 3.29.1.
The attributes of the AlternativeIndicatorID class are:
restriction
Optional. ENUM. See Section 3.3.1.
ext-restriction
Optional. STRING. A means by which to extend the restriction
attribute. See Section 5.1.1.
Notes:
Change: Update Section 3.29.1 to show that AlternativeIndicatorID contains IndicatorIDs, not IndicatorReferences.
From the notations part of the introduction (Section 1.2), the UML diagrams in Section 3 are non-normative, and the "IODEF Data Model (XML Schema)" in Section 8 is normative.
If my understanding of the text is correct, this means that if the UML diagrams conflict with the schema in Section 8, the schema in Section 8 is correct, and the UML diagrams must be changed to align with the schema in Section 8.
Page 153 of the document contains the (normative) AlternativeIndicatorID schema from Section 8:
<xs:element name="AlternativeIndicatorID">
<xs:complexType>
<xs:sequence>
<xs:element ref="iodef:IndicatorID" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="restriction"
type="iodef:restriction-type" use="optional"/>
<xs:attribute name="ext-restriction"
type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
From the above schema, the AlternativeIndicatorID is a sequence of IndicatorID, not the sequence of IndicatorReference implied by Section 3.29.2 (Figure 61 and the accompanying text). Thus, if I understand the document correctly, Section 3.29.2 must be changed to something more like the "Corrected Text" in this report.
Errata ID: 5582
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Takeshi Takahashi
Date Reported: 2018-12-25
Section 8 says:
<xs:simpleType name="contact-role-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/>
<xs:enumeration value="reporter"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="tech"/>
<xs:enumeration value="provider"/>
<xs:enumeration value="user"/>
<xs:enumeration value="billing"/>
<xs:enumeration value="legal"/>
<xs:enumeration value="abuse"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="cc-irt"/>
<xs:enumeration value="leo"/>
<xs:enumeration value="vendor"/>
<xs:enumeration value="vendor-services"/>
It should say:
<xs:simpleType name="contact-role-type">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="creator"/>
<xs:enumeration value="reporter"/>
<xs:enumeration value="admin"/>
<xs:enumeration value="tech"/>
<xs:enumeration value="provider"/>
<xs:enumeration value="user"/>
<xs:enumeration value="billing"/>
<xs:enumeration value="legal"/>
<xs:enumeration value="abuse"/>
<xs:enumeration value="irt"/>
<xs:enumeration value="cc"/>
<xs:enumeration value="cc-irt"/>
<xs:enumeration value="leo"/>
<xs:enumeration value="vendor"/>
<xs:enumeration value="vendor-support"/>
Notes:
In section 3.9, the body text says that the role attribute can take the value "vendor-support," but the schema says that the role can take the value "vendor-services." This inconsistency needs to be solved.
Errata ID: 5590
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Logan Widick
Date Reported: 2019-01-04
Section 3.18 says:
The Node class identifies a system, asset, or network and its
location.
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ DomainData ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..*}--[ Location ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 34: The Node Class
The aggregate classes of the Node class are:
DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.
Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1.
PostalAddress
Zero or one. POSTAL. The postal address of the node.
Location
Zero or more. ML_STRING. A free-form text description of the
physical location of the node. This description may provide a
more detailed description of where at the address specified by the
PostalAddress class this node is found (e.g., room number, rack
number, or slot number in a chassis).
It should say:
The Node class identifies a system, asset, or network and its
location.
+---------------+
| Node |
+---------------+
| |<>--{0..*}--[ DomainData ]
| |<>--{0..*}--[ Address ]
| |<>--{0..1}--[ PostalAddress ]
| |<>--{0..*}--[ Location ]
| |<>--{0..*}--[ Counter ]
+---------------+
Figure 34: The Node Class
The aggregate classes of the Node class are:
DomainData
Zero or more. The domain (DNS) information associated with this
node. If an Address is not provided, at least one DomainData MUST
be specified. See Section 3.19.
Address
Zero or more. The hardware, network, or application address of
the node. If a DomainData is not provided, at least one Address
MUST be specified. See Section 3.18.1.
PostalAddress
Zero or one. The postal address of the node. See Section 3.9.2.
Location
Zero or more. ML_STRING. A free-form text description of the
physical location of the node. This description may provide a
more detailed description of where at the address specified by the
PostalAddress class this node is found (e.g., room number, rack
number, or slot number in a chassis).
Notes:
According to "Section 8: The IODEF Data Model (XML Schema)", the Node class structure is the following:
<xs:element name="Node">
<xs:complexType>
<xs:sequence>
<xs:choice maxOccurs="unbounded">
<xs:element ref="iodef:DomainData"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Address"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
<xs:element ref="iodef:PostalAddress" minOccurs="0"/>
<xs:element ref="iodef:Location"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="iodef:Counter"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
Note that the schema is referring to the PostalAddress class (iodef:PostalAddress) instead of the "PAddress" (POSTAL) member of the PostalAddress class. Also, the UML diagram (Figure 34) and other parts of Section 3.18 refer to the PostalAddress class instead of the "PAddress" (POSTAL) member of the PostalAddress class. Thus, the "PostalAddress" field of the Node class is most likely an instance of the PostalAddress class, and not the POSTAL type stated in the text.
The corrected text ("The aggregate classes of the Node class are... PostalAddress") includes a reference to the PostalAddress class ("See Section 3.9.2") instead of the "POSTAL." type.
Errata ID: 6163
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-10
Section 7.2 says:
An example of C2 domains from a given campaign.
<?xml version="1.0" encoding="UTF-8"?>
<!-- A list of C2 domains associated with a campaign -->
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/
iodef-2.0.xsd">
<Incident purpose="watch" restriction="green">
<IncidentID name="csirt.example.com">897923</IncidentID>
<RelatedActivity>
<ThreatActor>
<ThreatActorID>
TA-12-AGGRESSIVE-BUTTERFLY
</ThreatActorID>
<Description>Aggressive Butterfly</Description>
</ThreatActor>
<Campaign>
<CampaignID>C-2015-59405</CampaignID>
<Description>Orange Giraffe</Description>
</Campaign>
</RelatedActivity>
<GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
<Description>Summarizes the Indicators of Compromise
for the Orange Giraffe campaign of the Aggressive
Butterfly crime gang.
</Description>
<Assessment>
<BusinessImpact type="breach-proprietary"/>
</Assessment>
<Contact type="organization" role="creator">
<ContactName>CSIRT for example.com</ContactName>
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
<IndicatorData>
<Indicator>
<IndicatorID name="csirt.example.com" version="1">
G90823490
</IndicatorID>
<Description>C2 domains</Description>
<StartTime>2014-12-02T11:18:00-05:00</StartTime>
<Observable>
<BulkObservable type="fqdn">
It should say:
An example of C2 domains from a given campaign.
<?xml version="1.0" encoding="UTF-8"?>
<!-- A list of C2 domains associated with a campaign -->
<IODEF-Document version="2.00" xml:lang="en"
xmlns="urn:ietf:params:xml:ns:iodef-2.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation=
"http://www.iana.org/assignments/xml-registry/schema/
iodef-2.0.xsd">
<Incident purpose="watch" restriction="green">
<IncidentID name="csirt.example.com">897923</IncidentID>
<RelatedActivity>
<ThreatActor>
<ThreatActorID>
TA-12-AGGRESSIVE-BUTTERFLY
</ThreatActorID>
<Description>Aggressive Butterfly</Description>
</ThreatActor>
<Campaign>
<CampaignID>C-2015-59405</CampaignID>
<Description>Orange Giraffe</Description>
</Campaign>
</RelatedActivity>
<GenerationTime>2015-10-02T11:18:00-05:00</GenerationTime>
<Description>Summarizes the Indicators of Compromise
for the Orange Giraffe campaign of the Aggressive
Butterfly crime gang.
</Description>
<Assessment>
<BusinessImpact type="breach-proprietary"/>
</Assessment>
<Contact type="organization" role="creator">
<ContactName>CSIRT for example.com</ContactName>
<Email>
<EmailTo>contact@csirt.example.com</EmailTo>
</Email>
</Contact>
<IndicatorData>
<Indicator>
<IndicatorID name="csirt.example.com" version="1">
G90823490
</IndicatorID>
<Description>C2 domains</Description>
<StartTime>2014-12-02T11:18:00-05:00</StartTime>
<Observable>
<BulkObservable type="domain-name">
Notes:
Neither the IODEF Data Model (XML Schema) in section 8 nor the main body in section 3.29.3.1 define a type named "fqdn" for the BulkObservable class.
Instead, section 3.29.3.1 states that the "domain-name" type is used to denote "A fully qualified domain name or part of a name (e.g., fqdn.example.com, example.com).". The XML schema agrees with that.
The example in section 7.2 was changed to comply with this definition.
Errata ID: 6168
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11
Section 2.17 says:
There is no original text (new section)
It should say:
2.17. Boolean A boolean is represented in the information model by the BOOLEAN data type. The BOOLEAN data type is implemented in the data model as an "xs:boolean" type per Section 3.2.2 of [W3C.SCHEMA.DTYPES].
Notes:
Section 2.16 defines "boolean" as a valid value for the "dtype" attribute, stating that "The element content is of type BOOLEAN.".
This is reinforced by the definition of "dtype-type" inside the XML schema in section 8 where "boolean" is indeed listed as a valid value.
However, the BOOLEAN type is never actually defined in the RFC.
This change adds a new section (tentatively named 2.17) under section 2 which defines the BOOLEAN type based on the definition of other types used by the RFC.
It might be preferable to put the new section near the beginning of section 2 with other primitive datatypes like INTEGER and REAL.
Please note that this change also impacts the table of contents.
Errata ID: 6169
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11
Section 4.4 says:
4.4. Incompatibilities with v1 The IODEF data model in this document makes a number of changes to [RFC5070]. These changes were largely additive -- classes and enumerated values were added. However, some incompatibilities between [RFC5070] and this new specification were introduced. These incompatibilities are as follows: o The IODEF-Document@version attribute is set to "2.0".
It should say:
4.4. Incompatibilities with v1 The IODEF data model in this document makes a number of changes to [RFC5070]. These changes were largely additive -- classes and enumerated values were added. However, some incompatibilities between [RFC5070] and this new specification were introduced. These incompatibilities are as follows: o The IODEF-Document@version attribute is set to "2.00".
Notes:
The XML schema in section 8, the main text in section 3.1 and every other occurrence in the document state that the IODEF-Document@version attribute has a fixed value of "2.00".
The impact of this change on the overall technical meaning is limited since the incompatibility with IODEF v1 still remains, plus, every other reference to this attribute is correct.
Errata ID: 6170
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-11
Section 3.29.3.1 says:
The attributes of the BulkObservable class are:
type
Optional. ENUM. The type of the observable listed in the child
ObservableList class. These values are maintained in the
"BulkObservable-type" IANA registry per Section 10.2.
1. asn. Autonomous System Number (per the Address@category
attribute).
2. atm. Asynchronous Transfer Mode (ATM) address (per the
Address@category attribute).
3. e-mail. Email address (per the Address@category attribute).
4. ipv4-addr. IPv4 host address in dotted-decimal notation,
e.g., 192.0.2.1 (per the Address@category attribute).
5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits, e.g., 192.0.2.0/24 (per the
Address@category attribute).
6. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation,
i.e., 192.0.2.0/255.255.255.0 (per the Address@category
attribute).
7. ipv6-addr. IPv6 host address, e.g., 2001:DB8::3 (per the
Address@category attribute).
8. ipv6-net. IPv6 network address, slash, significant bits,
e.g., 2001:DB8::/32 (per the Address@category attribute).
9. ipv6-net-mask. IPv6 network address, slash, network mask
(per the Address@category attribute).
10. mac. Media Access Control (MAC) address, i.e., a:b:c:d:e:f
(per the Address@category attribute).
11. site-uri. A URL or URI for a resource (per the
Address@category attribute).
12. domain-name. A fully qualified domain name or part of a name
(e.g., fqdn.example.com, example.com).
13. domain-to-ipv4. A mapping of FQDN to IPv4 address specified
as a comma-separated list (e.g., "fqdn.example.com,
192.0.2.1").
14. domain-to-ipv6. A mapping of FQDN to IPv6 address specified
as a comma-separated list (e.g., "fqdn.example.com,
2001:DB8::3").
15. domain-to-ipv4-timestamp. Same as domain-to-ipv4 but with a
timestamp (in the DATETIME format) of the resolution (e.g.,
"fqdn.example.com, 192.0.2.1, 2015-06-11T00:38:31-06:00").
16. domain-to-ipv6-timestamp. Same as domain-to-ipv6 but with a
timestamp (in the DATETIME format) of the resolution (e.g.,
"fqdn.example.com, 2001:DB8::3, 2015-06-11T00:38:31-06:00").
17. ipv4-port. An IPv4 address, port, and protocol tuple (e.g.,
192.0.2.1, 80, TCP). The protocol name corresponds to the
"Keyword" column in the "Assigned Internet Protocol Numbers"
registry [IANA.Protocols].
18. ipv6-port. An IPv6 address, port, and protocol tuple (e.g.,
2001:DB8::3, 80, TCP). The protocol name corresponds to the
"Keyword" column in the "Assigned Internet Protocol Numbers"
registry [IANA.Protocols].
19. windows-reg-key. A Microsoft Windows registry key.
20. file-hash. A file hash. The format of this hash is
described in the Hash class that MUST be present in a sibling
BulkObservableFormat class.
It should say:
The attributes of the BulkObservable class are:
type
Optional. ENUM. The type of the observable listed in the child
ObservableList class. These values are maintained in the
"BulkObservable-type" IANA registry per Section 10.2.
1. asn. Autonomous System Number (per the Address@category
attribute).
2. atm. Asynchronous Transfer Mode (ATM) address (per the
Address@category attribute).
3. e-mail. Email address (per the Address@category attribute).
4. ipv4-addr. IPv4 host address in dotted-decimal notation,
e.g., 192.0.2.1 (per the Address@category attribute).
5. ipv4-net. IPv4 network address in dotted-decimal notation,
slash, significant bits, e.g., 192.0.2.0/24 (per the
Address@category attribute).
6. ipv4-net-mask. IPv4 network address in dotted-decimal
notation, slash, network mask in dotted-decimal notation,
i.e., 192.0.2.0/255.255.255.0 (per the Address@category
attribute).
7. ipv6-addr. IPv6 host address, e.g., 2001:DB8::3 (per the
Address@category attribute).
8. ipv6-net. IPv6 network address, slash, significant bits,
e.g., 2001:DB8::/32 (per the Address@category attribute).
9. ipv6-net-mask. IPv6 network address, slash, network mask
(per the Address@category attribute).
10. mac. Media Access Control (MAC) address, i.e., a:b:c:d:e:f
(per the Address@category attribute).
11. site-uri. A URL or URI for a resource (per the
Address@category attribute).
12. domain-name. A fully qualified domain name or part of a name
(e.g., fqdn.example.com, example.com).
13. domain-to-ipv4. A mapping of FQDN to IPv4 address specified
as a comma-separated list (e.g., "fqdn.example.com,
192.0.2.1").
14. domain-to-ipv6. A mapping of FQDN to IPv6 address specified
as a comma-separated list (e.g., "fqdn.example.com,
2001:DB8::3").
15. domain-to-ipv4-timestamp. Same as domain-to-ipv4 but with a
timestamp (in the DATETIME format) of the resolution (e.g.,
"fqdn.example.com, 192.0.2.1, 2015-06-11T00:38:31-06:00").
16. domain-to-ipv6-timestamp. Same as domain-to-ipv6 but with a
timestamp (in the DATETIME format) of the resolution (e.g.,
"fqdn.example.com, 2001:DB8::3, 2015-06-11T00:38:31-06:00").
17. ipv4-port. An IPv4 address, port, and protocol tuple (e.g.,
192.0.2.1, 80, TCP). The protocol name corresponds to the
"Keyword" column in the "Assigned Internet Protocol Numbers"
registry [IANA.Protocols].
18. ipv6-port. An IPv6 address, port, and protocol tuple (e.g.,
2001:DB8::3, 80, TCP). The protocol name corresponds to the
"Keyword" column in the "Assigned Internet Protocol Numbers"
registry [IANA.Protocols].
19. windows-reg-key. A Microsoft Windows registry key.
20. file-hash. A file hash. The format of this hash is
described in the Hash class that MUST be present in the child
BulkObservableFormat class.
Notes:
The description for the "file-hash" type implies that the BulkObservableFormat class (3.29.3.1.1) is a sibling of the BulkObservable class (section 3.29.3.1).
This is simply not the case:
* BulkObservable only appears as an aggregate class of Observable (3.29.3)
* BulkObservableFormat is not one of Observable's aggregate classes
Since the BulkObservable class actually has an aggregate class named BulkObservableFormat, the intent was probably to just use that child class to define the hash's format.
Errata ID: 6177
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: François Poirotte
Date Reported: 2020-05-17
Section 3.26 says:
3.26. HashData Class
The HashData class describes different types of hashes on a given
object (e.g., file, part of a file, email).
+--------------------------+
| HashData |
+--------------------------+
| ENUM scope |<>--{0..1}--[ HashTargetID ]
| |<>--{0..*}--[ Hash ]
| |<>--{0..*}--[ FuzzyHash ]
+--------------------------+
Figure 54: The HashData Class
It should say:
3.26. HashData Class
The HashData class describes different types of hashes on a given
object (e.g., file, part of a file, email).
+--------------------------+
| HashData |
+--------------------------+
| ENUM scope |<>--{0..1}--[ HashTargetID ]
| STRING ext-scope |<>--{0..*}--[ Hash ]
| |<>--{0..*}--[ FuzzyHash ]
+--------------------------+
Figure 54: The HashData Class
Notes:
Both the main body inside section 3.26 & the XML schema in section 8 mention "ext-scope" as a valid attribute of the HashData class, but the attribute was missing from the UML diagram in section 3.26.
(The attribute is necessary so that the "scope" attribute of HashData can be extended using the principles edicted in section 5.1.1)