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