[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-cybox] Re: CybOX 3.0: HashType Refactoring
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
Attachment:
signature.asc
Description: PGP signature
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]