HI Allan,
The critical word in the text Iâm suggesting is âcontributingâ. This is the name we gave the collection of properties that should be included in a deterministic id. For example, here is the text from the
X509 certificate table:
|
ID Contributing Properties |
|
hashes,
serial_number If the hashes property is present, include only one hash. The selected hash
SHOULD come from this ordered list (based on the following order of preference) [ MD5, SHA-1, SHA-256, SHA-512 ]. |
If you look at the definitions of those two properties, they are both listed as âoptionalâ.
As it turns out, when I was creating deterministic ids for the examples in the spec â here was one for X509 certificates:
Examples
Basic X.509 certificate
{
"type": "x509-certificate",
"spec_version": "2.1",
"issuer": "C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com",
"validity_not_before": "2016-03-12T12:00:00Z",
"validity_not_after": "2016-08-21T12:00:00Z",
"subject": "C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org
}
Notice that neither the hashes or serial number property is present. So how could I create a deterministic id for this example?
For the sake of getting the working draft out â I just added the serial_number property â and therefore I was able to create the deterministic id for it. Here is what this example now looks like in the working
draft.
Examples
Basic X.509 certificate
{
"type": "x509-certificate",
"spec_version": "2.1",
"id": "x509-certificate--463d7b2a-8516-5a50-a3d7-6f801465d5de",
"issuer": "C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Server CA/emailAddress=server-certs@thawte.com",
"validity_not_before": "2016-03-12T12:00:00Z",
"validity_not_after": "2016-08-21T12:00:00Z",
"subject": "C=US, ST=Maryland, L=Pasadena, O=Brent Baccala, OU=FreeSoft, CN=www.freesoft.org/emailAddress=baccala@freesoft.org",
"serial_number": "36:f7:d4:32:f4:ab:70:ea:d3:ce:98:6e:ea:99:93:49:32:0a:b7:06"
}
There are several other SCOs where the contributing properties are all optional (e.g., email_message). In most SCOs, it is highly unlikely that all of the contributing properties will be omitted.
But the original example from the spec shows that is could happen. The new normative text is to handle this case.
Rich
--
Rich Piazza
The MITRE Corporation
781-271-3760
From: Allan Thomson <athomson@lookingglasscyber.com>
Date: Friday, August 16, 2019 at 4:31 PM
To: Rich Piazza <rpiazza@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXT] Re: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification
Rich â I think we need an example because on the surface your suggestion makes sense but I want to understand the following.
What object has is worth conveying if *all* the properties are optional *and* *all* of them are
empty. What exactly is that object conveying then? It sounds like an empty object with no actual content.
I question the definition of the object in the 1st place so I assume thereâs a specific example that helps show that your change is helping.
But my concern about adding the language you are suggesting is actually more on what object has this problem.
Allan Thomson
CTO (+1-408-331-6646)
From: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org> on behalf of "Piazza, Rich" <rpiazza@mitre.org>
Date: Friday, August 16, 2019 at 11:45 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Adding some text to the deterministic ID description in section 2.9 of the STIX specification
As MITRE was incorporating deterministic ids into cti-python-stix2 API, the implementer came across the issue that I mentioned on one of the working calls. That is â what if the contributing properties are
all optional, and none of them are present in the object? What should the ID be?
The most obvious answer (to me) is that a UUIDv4 should be used in these cases. However, no text exists in the specification to clarify this. Iâm suggesting the following be added to section 2.9 as the fourth
bullet point of the paragraph which begins âSTIX Cyber-observable Objects SHOULD use UUIDv5ââ
- If the contributing properties are all optional, and none are present on the SCO, then a UUIDv4
SHOULD be used.
Bret and I discussed this, and even though it is a new normative statement, we feel that it is not really a substantive change.
This will be discussed on the next working call.
Rich
--
Rich Piazza
The MITRE Corporation
781-271-3760
