I think that email message should default to UUIDv4 in most cases.
In general email messages shouldnât deduplicate with the use cases to deduplicate them being:
1. Itâs the exact same email message and thatâs what weâre tracking in which case message_id should be used as the basis of this determination if possible.
2. We are tracking a more abstract layer in which case we want to build an ID based on the emailâs subject, body and attachments. When using email in this manner external relationships need to be used to point to the sender, and recipients since they werenât all included in one email, but instead received an email that from a CTI perspective was identical.
Jeffrey Mates, Civ DC3/TSD
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Computer Scientist
Technical Solutions Development
jeffrey.mates@dc3.mil
410-694-4335
From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Piazza, Rich
Sent: Friday, June 21, 2019 12:40 PM
To: cti@lists.oasis-open.org
Subject: [Non-DoD Source] [cti] More on ID Contributing Properties
In the STIX spirit of implementing proposed specification additions, I have been implementing a script to generate deterministic IDs â which I have commented on before.
I noticed something else which seems ambiguous â the use of optional properties. For example, letâs take an email-message. The three ID contributing properties are: from_ref, subject, body.
Both are subject and body optional. Assuming both are not present, then only from_ref will be used. Therefore, any email message from the same email address, for which both the subject and body are empty (or not provided in the email-message object), will have the same deterministic ID. However, the email-message objects might be very different â i.e., many non-contributing properties exists in both that are not the same.
So a collision will take place. Receiving two SCOs with the same id was supposed to a feature â you didnât have to retain both, but in this case you really have two different objects â both of which should probably be retained (e.g., different date properties).
Additionally, this problem can also exist even with required only contributing properties.
Iâm aware that this is a known limitation, and perhaps it has already been taken into consideration, as I was not part of the subgroup that developed deterministic IDs. But maybe we can do a little better â for instance:
- Include more contributing properties. For instance, adding the date property as a contributing property of the email-message object would help to avoid collisions.
- Distinguish non-existent properties in the actual object from ones not provided in the STIX object â i.e., if the subject was really empty â provide the subject property with a value of ââ. Some normative text (SHOULD) could be added.
- Use UUIDv4 if the number of non-contributing properties is over some threshold â chances are there wonât be another similar object.
Rich
--
Rich Piazza
The MITRE Corporation
781-271-3760
