OASIS Cyber Threat Intelligence (CTI) TC

I would support removing the requirements altogether.
If we keep the requirements, I think they should match.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com

From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, June 1, 2018 at 9:12 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Minor spec question: minimum characters for custom property/object names


 

Hi all,
 
We discussed a minor topic on this past working call and I wanted to summarize the discussion and see if anyone else had any thoughts. Notes from the working call
are here: https://www.oasis-open.org/committees/download.php/63164/OASIS-CTI-TC_WorkingCall_May29_2018.pdf
 
The specific text is in Part 1, Sections 8.1.1 [1] and 8.2.1 [2]. Currently, we have a normative MUST requirement that all custom property names and custom object
names be at least three characters long. This was set in place when, in the specification, we also had a normative MUST for the dictionary type to require properties be longer than two characters. In developing support for internationalization, though, Emmanuelle
noticed a bug [3] where this conflicted with the property names required by i18n, ISO language codes, which can be only two characters long. So, we changed the requirement in the text for dictionary to allow for two-character key names in dictionaries.
 
Custom properties and objects are a separate topic, but since the text was originally the same we wanted to bring it up for discussion. We talked about it on the
working call this past week and the discussion seemed to land on it not being a huge deal and that we should leave the text as-is. This would mean that, though you can use keys in a dictionary that are only 1 or 2 characters long (including ISO language codes),
custom property and object names would still have to be three characters long.
 
Does anybody object to keeping this as-is, per the working call discussion? The other options would be to either change the requirement to a minimum of two characters
(effectively allowing everything except one character names) or to remove the requirements altogether.
 
Thanks for your feedback,
John
 
[1]:
https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.3a2x3jdr23tq
[2]:
https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.u7ks5xud8vj0

[3]:
https://github.com/oasis-tcs/cti-stix2/issues/35


This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments thereto) by others is strictly prohibited.
If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Thanks Sean.
 
My e-mail probably wasn’t clear, the requirement was removed completely from dictionary but still exists for custom properties and custom objects. It’s not like it’s 3 for custom stuff and 2 for dictionaries.
So I don’t think we have inconsistent requirements, we just only have the requirements when they apply to custom stuff. Given that would you be OK as-is?
 
John
 

From: Sean Barnum <sean.barnum@FireEye.com>
Date: Friday, June 1, 2018 at 10:39 AM
To: John Wunder <jwunder@mitre.org>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: Re: [cti] Minor spec question: minimum characters for custom property/object names


 

I would support removing the requirements altogether.
If we keep the requirements, I think they should match.
 

Sean Barnum
Principal Architect
FireEye
M: 703.473.8262

E: sean.barnum@fireeye.com

From: <cti@lists.oasis-open.org> on behalf of "Wunder, John A." <jwunder@mitre.org>
Date: Friday, June 1, 2018 at 9:12 AM
To: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [cti] Minor spec question: minimum characters for custom property/object names


 

Hi all,
 
We discussed a minor topic on this past working call and I wanted to summarize the discussion and see if anyone else had any thoughts. Notes from the working call are here:
https://www.oasis-open.org/committees/download.php/63164/OASIS-CTI-TC_WorkingCall_May29_2018.pdf
 
The specific text is in Part 1, Sections 8.1.1 [1] and 8.2.1 [2]. Currently, we have a normative MUST requirement that all custom property names and custom object names be at least three characters long. This
was set in place when, in the specification, we also had a normative MUST for the dictionary type to require properties be longer than two characters. In developing support for internationalization, though, Emmanuelle noticed a bug [3] where this conflicted
with the property names required by i18n, ISO language codes, which can be only two characters long. So, we changed the requirement in the text for dictionary to allow for two-character key names in dictionaries.
 
Custom properties and objects are a separate topic, but since the text was originally the same we wanted to bring it up for discussion. We talked about it on the working call this past week and the discussion
seemed to land on it not being a huge deal and that we should leave the text as-is. This would mean that, though you can use keys in a dictionary that are only 1 or 2 characters long (including ISO language codes), custom property and object names would still
have to be three characters long.
 
Does anybody object to keeping this as-is, per the working call discussion? The other options would be to either change the requirement to a minimum of two characters (effectively allowing everything except
one character names) or to remove the requirements altogether.
 
Thanks for your feedback,
John
 
[1]: https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.3a2x3jdr23tq
[2]: https://docs.google.com/document/d/1ShNq4c3e1CkfANmD9O--mdZ5H0O_GLnjN28a_yrEaco/edit#heading=h.u7ks5xud8vj0

[3]: https://github.com/oasis-tcs/cti-stix2/issues/35

This email and any attachments thereto may contain private, confidential, and/or privileged material for the sole use of the intended recipient. Any review, copying, or distribution of this email (or any attachments
thereto) by others is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.

Thank you for the clarification.
Honestly, I have never really seen the value in having those restrictions and think we would be better off without them.
Is there anyone arguing for the remaining restriction to stay in place? If not, then why not remove it as well to be consistent? Unless there is someone arguing to keep it, this does not seem like it would
be huge time sink to change.
I don’t want to go down a huge rabbit hole explaining pedantic details (I am sure you don’t want me too either

From a programmatic perspective it can be useful since some systems use very short key values for internal purposes.  It’s also helpful to avoid overlap between custom fields defined by different groups for widely different purposes none of which can be explained since the keys for such values are things like “a”, “x” and “qr”.   Jeffrey Mates, Civ DC3/DCCI ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Computer Scientist Defense Cyber Crime Institute jeffrey.mates@dc3.mil 410-694-4335   From: cti@lists.oasis-open.org <cti@lists.oasis-open.org> On Behalf Of Sean Barnum Sent: Friday, June 1, 2018 11:47 AM To: Wunder, John A. <jwunder@mitre.org>; cti@lists.oasis-open.org Subject: [Non-DoD Source] Re: [cti] Minor spec question: minimum characters for custom property/object names   Thank you for the clarification. Honestly, I have never really seen the value in having those restrictions and think we would be better off without them. Is there anyone arguing for the remaining restriction to stay in place? If not, then why not remove it as well to be consistent? Unless there is someone arguing to keep it, this does not seem like it would be huge time sink to change. I don’t want to go down a huge rabbit hole explaining pedantic details (I am sure you don’t want me too either