Re: [cti-cybox] Recent CybOX Changes

["Jason Keirstead" <Jason.Keirstead@ca.ibm.com>]

I agree with John-Mark that these latest changes seem impractical to me.

Also, I am unsure why any of this is needed all of a sudden (what is the use case for capturing an observed encoding?) or why it needs to be done on a string-by-string basis. Can anyone go into more details as to what is attempted to be accomplished here? It wasn't explained very well on the list, simply "This type permits the capture of observed encodings for strings in Objects wherever appropriate ". But, *when* is it appropriate? Why would this be useful to anyone...

-
Jason Keirstead
STSM, Product Architect, Security Intelligence, IBM Security Systems
www.ibm.com/security | www.securityintelligence.com

Without data, all you are is just another person with an opinion - Unknown


John-Mark Gurney ---08/01/2016 08:55:35 PM---Kirillov, Ivan A. wrote this message on Mon, Aug 01, 2016 at 18:16 +0000: > Also, Trey, Allan, and I

From: John-Mark Gurney <jmg@newcontext.com>
To: "Kirillov, Ivan A." <ikirillov@mitre.org>
Cc: Allan Thomson <athomson@lookingglasscyber.com>, "Wunder, John A." <jwunder@mitre.org>, "Back, Greg" <gback@mitre.org>, "cti-cybox@lists.oasis-open.org" <cti-cybox@lists.oasis-open.org>
Date: 08/01/2016 08:55 PM
Subject: Re: [cti-cybox] Recent CybOX Changes
Sent by: <cti-cybox@lists.oasis-open.org>

---

Kirillov, Ivan A. wrote this message on Mon, Aug 01, 2016 at 18:16 +0000:
> Also, Trey, Allan, and I briefly talked about this earlier today and we thought it might be better to remove the “OR” between string and string-with-encoding-type in those instances where we thought observed encoding could be captured, and instead just force those fields to use string-with-encoding-type. This means that you’ll always specify and parse those fields as an object, leading to less branches in your code. We’ve made this change in the CybOX Objects – let us know what you think (is it an improvement?). 

It is better to always use one object instead of an or... But I still
prefer using the _enc field, as flatter is better.. :)

> As far as file path, are there other thoughts on this as far as the preferable approach (single string vs. list of path component strings)? Trey and I are a little hesitant to change our current implementation because it seemed like we had consensus on this when we were creating and reviewing the File Object. That said, if the group feels that having a single string for representation of file paths is enough, we’ll be happy to go in that direction.

I disagree w/ using string-with-encoding-type for the file-path-type...
The entire path will will be a single encoding... Each segment of the
path will not have a different encoding..  IMO, right now it's ridiculous:
{ "delimiter": "/",
  "components": [
                 { "value": "opt",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "local",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "Library",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "Frameworks",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "Python.framekwork",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "Versions",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "2.7",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "lib",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "python2.7",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "site-packages",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "Crypto",
                   "encoding": "ISO-8859-15"
                 },
                 { "value": "__init__.pyc",
                   "encoding": "ISO-8859-15"
                 }
                 ]
}

vs:
{ "delimiter": "/",
  "components": [ "opt",
                                  "local",
                                  "Library",
                                  "Frameworks",
                                  "Python.framekwork",
                                  "Versions",
                                  "2.7",
                                  "lib",
                                  "python2.7",
                                  "site-packages",
                                  "Crypto",
                                  "__init__.pyc" ],
  "components_enc": "ISO-8859-15"
}

-- 
John-Mark

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php