[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [cti-users] âSignatureâ of STIX Objects
@Jason thanks for that link. Good reading! @Bret: Agreed! So from implementation my view was (of course not locked down, as i have yet to write the code ! ;) ): To implement the âreaderâ of the json as a way to navigate the data, not necessarily a way to recreate the signed representation.. So the âlibraryâ is consuming the JSON and validates that JSON with the signature. Like @Bret mentions in his linked post (http://making-security-measurable.1364806.n2.nabble.com/STIX-STIX-1-2-Multiple-Descriptions-JSON-Options-td7587294i20.html#a7587336), âwhere to validate againstâ is a issue.  So this is where the âstrategyâ comes into play. But as the most simple of implementations, it would be to maintain a list of trusted sources. This is not ideal nor standardized; But I will leave the standards up to the people working on the white papers! So a âx_signatureâ property would likely contain who issued it, and that content would be cross-ref with the consumerâs list of âtrusted sourcesâ, and the specific coded strategy does the validation. This can obviously be greatly improved: but my goal is object at rest validation and not just during initial receipt. The object should be able to be signed and passed around, stored (, etc. Like a signature on a digital document, or a JWT key. If you want to get extra fancy you could possibly get into a array of signatures as older signatures expire and you want to revalidate. But thats a whole other problem space for future work. If worse case occurs and there is risk that consumerâs cannot re-create the canonical representation (for the number type issue or whatever issue), then I believe I would store/keep the canonical representation / the original json string representation that was submitted, and keep it with the processed/in-mem object: meaning that there would be the âprocessedâ object and the âraw objectâ which is the original raw string received. This starts to double storage needs;   This storage is only needed if you are re-transmitting the data, or you are a consumer who needs to re-validate the upstream data sometime in the future. If you are a general consumer and not a re-distributor (you may distribute but it is only your own content), then generally you only need to validate your STIX data on receipt, and mark in your CTI system that it is valid. As a standard gets created over time, raw representations can be removed, and the rest seemingly remains the same. From:ÂBret Jordan <jordan2175@gmail.com> Reply:ÂBret Jordan <jordan2175@gmail.com> Date:ÂNovember 23, 2018 at 2:39:38 PM To:ÂStephen Russett <stephen@digitalstate.ca> Cc:Âcti-users@lists.oasis-open.org <cti-users@lists.oasis-open.org> Subject: Re: [cti-users] âSignatureâ of STIX Objects
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]