The Nil UUID gets rejected as invalid UUID

[lava]

Trying to reference a stix object with a UUID of note--00000000-0000-0000-0000-000000000000 results in an exception according to the changes implemented in #188, because the all-zero uuid is not a UUIDv4:

stix2.exceptions.InvalidValueError: Invalid value for Sighting 'sighting_of_ref': not a valid STIX identifier, must match <object-type>--<UUID>: note--00000000-0000-0000-0000-000000000000

However, it looks like the standard wording has been loosened in the meantime, since now the only binding requirement I can see in the UUID description is this:

All identifiers, excluding those used in the deprecated Cyber Observable Container, MUST follow the form object-type--UUID, where object-type is the exact value (all type names are lowercase strings, by definition) from the type property of the object being identified or referenced and where the UUID MUST be an RFC 4122-compliant UUID [RFC4122]. 

And RFC 4122 includes the following:

4.1.7.  Nil UUID

   The nil UUID is special form of UUID that is specified to have all
   128 bits set to zero.

So based on my reading, this should be accepted as an UUID.

(Context: We ran across this when we attempted to use the nil UUID as a dummy value to signal that we're unable to provide a valid STIX SDO for some required property. This issue is a bit arcane in the sense that we will have to switch to a better solution anyways in the short term, but I think technically it should have been allowed to create this UUID.)

[chisholm]

Hmmm... the RFC defines variant bits "0 x x" as "Reserved, NCS backward compatibility" (and therefore outside the RFC 4122 spec), and then defines a UUID with those variant bits anyway. Seems like a bit of an awkward inconsistency. Or is it merely assigning a name to the UUID without claiming that it falls under the umbrella of a RFC 4122 variant UUID? Or maybe the STIX spec intentionally says RFC 4122 compliant, which the authors treat as not being the same as RFC 4122 variant? I wonder if the STIX spec authors were thinking that way and intending to make a distinction?

It follows from RFC 4122 section 4.1.1 that a UUID with all zero bits can't be RFC 4122 variant. That's what the stix2 library code checks. I don't know what the STIX 2.1 spec authors' intent was for this.

[lava]

I would read RFC 4.1.7 as providing a one-off exception that is valid in addition to the UUIDs that follow the rules from 4.1.1 - 4.1.6, but I agree that the RFC itself seems a bit self-contradictory on this point.

[clenk]

I doubt the STIX spec authors thought about this circumstance when choosing their words. I believe they merely wanted to avoid reinventing the wheel and so referenced the RFC.

This library relies on the uuid python module, which interprets the nil UUID as the RESERVED_NCS variant rather than the RFC_4122 variant.

Is the issue that your solution is under development and the code for that SDO hasn't been written yet, or is there a use case where a valid SDO cannot be provided for something required in STIX? If it's the latter and you're able to share more, maybe the STIX spec needs to be updated to support it.

[lava]

@clenk Sure, it's the latter actually. We have a bloom filter continously scanning some incoming telemetry that can generate a Sighting from matches. This can also be configured to run in a probabilistic mode where we only know that we had a match (up to some false positive probability) and the event data that generated the match, but don't know the actual indicator that we matched until some later step in the pipeline.

See also tenzir/threatbus#176 for more context.

[clenk]

@lava thanks for the context. Do you need to publish the Sighting before publishing the Indicator? If you publish them at the same time, then you could collect the data needed to create the Sighting, but wait until later in the pipeline when you have the Indicator as well to create the Sighting.

[clenk]

I suppose if that's not possible you could use a dummy Indicator instead of a dummy uuid. But you'd have to come up with a dummy pattern too. Not the cleanest solution.