OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cti-cybox message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cti-cybox] Re: CybOX 3.0: HashType Refactoring


I think Trey said it well below - our focus for 3.0 is on refactoring the most widely used set of types and Objects with a focus towards simplicity and ease-of-use. To that end, it makes sense to use enumerations instead of controlled vocabularies wherever appropriate.

Also, just a note that I’ve updated the HashType proposal to take these recent discussions into account, and also added a notional JSON schema for those interested: https://github.com/CybOXProject/schemas/wiki/CybOX-3.0:-HashType-Refactoring

Regards,
Ivan 


On 11/4/15, 6:21 AM, "Trey Darley" <trey@soltra.com> wrote:

>On 03.11.2015 15:32:09, Kirillov, Ivan A. wrote:
>> Yes, I absolutely agree on the utility of enumerations, and I
>> probably should have clarified my point accordingly. Anyhow, my
>> thought is that the “type” field in HashType should NOT be
>> implemented through a controlled vocabulary but should instead yse a
>> fixed enumeration that is defined as part of the CybOX 3.0
>> specification:
>> 
>> 
>> “type": {
>>             "enum": [ “md5", “md5", “sha1”, “sha256”, etc.  ]}
>> 
>
>
>To Ivan's point, what we're currently focusing on for CybOX 3.0 is
>refactoring a *core* set of objects. Cf. the previous discussion
>around the IP address object, while I suspect that we'll see new
>cryptographic hashing algorithms well before we bump into IPv8, the
>pace of development isn't happening at lightspeed either.
>
>Mark raised a good point earlier about trying to avoid rampant use of
>controlled vocabularies and enforcing an MTI where they are used. To
>me, controlled vocabularies add most value (at the cost of added
>complexity for the implementer!) with objects that are likely to
>evolve quickly. I would argue that these are out of scope for our
>current focus on refactoring core CybOX primitives.
>
>QED, I think it makes sense to define a simple enum of the most common
>types, allow for an 'other' override in case somebody wants to use
>SuperCyberQuantumCryptoHash, and if/when other algorithms come into
>widespread use, we can extend the core enum in a future revision of
>CybOX.
>
>-- 
>Cheers,
>Trey
>--
>Trey Darley
>Senior Security Engineer
>4DAA 0A88 34BC 27C9 FD2B  A97E D3C6 5C74 0FB7 E430
>Soltra | An FS-ISAC & DTCC Company
>www.soltra.com
>--
>"One size never fits all." --RFC 1925


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]