Re: [cti-users] âSignatureâ of STIX Objects

[Stephen Russett <stephen@digitalstate.ca>]

Hi John-Mark

Thanks for the link. I gave your spec proposal a good read.

Few questions I am trying to reconcile with your write up:

1. Why do you propose to carry signatures along in their own SDO?
   
   
2. Why is there a distinction of signing a SDO/SRO vs cyber observable?
   
   
3. Your note about the size of json numbers is a good spec point; this would already be covered in the spec as per:Âhttp://docs.oasis-open.org/cti/stix/v2.0/cs01/part1-stix-core/stix-v2.0-cs01-part1-stix-core.html#_Toc496709266Â?Âwhere the JS interop spec would cover the max range. This becomes a implementation detail to enforce number sizes during serialization and deserialization.
   
   
4. The structure you outline seems to be layers on-top of existing PKI trust models and very similar to what JWT tokens impose?
   
   
5. You mention web of trust at the bottom of the document: ÂIs this something you are looking to achieve? Do you want to be maintaining the complexities of Wot?
   
   
6. This question:Âhttps://github.com/oasis-tcs/cti-stix2/issues/118Âseems relevant to the context of relations. Given that relations are managed as strings rather than objects thus no additional data can be applied to the object (such as a hash, signature, context info, etc), I think it could make sense to visit this issue. If relations inside of a object can be given context (with additional attributes specific to that relation) and the parent object signed, then it would seem you can remove the issue of signing chains with related content.
   
   
7. What are the reasons for not signing Bundle, Marking Definitions, and cyber observables? (basically having the ability to sign all bundleable objects.
   
   
8. Why do you want to store the signature specific additional attributes in the object level rather than only in the encoded version? Additionally would it make sense to use a existing standard? such as a premise of using JWT practices to encode and sign the object.

Thanks

Steve

From:ÂJohn-Mark Gurney <jmg@newcontext.com>
Reply:ÂJohn-Mark Gurney <jmg@newcontext.com>
Date:ÂDecember 7, 2018 at 7:44:40 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

Stephen Russett wrote this message on Fri, Nov 23, 2018 at 10:44 -0800:
> Hey all
>
> I am looking for some experiences working with âsigningâ objects (SDOs,
> SROs, Data Marking Definitions, etc). I am looking at using a custom
> property, but wanted to get some feedback if others are doing this?
>
> use case: As bundles are passed around in STIX, There are different
> actors/identities that are consuming this information. Has there been
> thought on a common standard for signing bundles and each item within a
> bundle (in the case where a bundleâs objects were provided by different
> actors, but was bundled by someone else).

Sorry, I just saw this email.

I have already written a proposal on signing, and I wrote the first proposal
almost two years ago.

Signing data needs to be handled very carefully as if it is not handled
properly, you can end up w/ attackers being able to pretend that data was
signed when it was not...

The latest version of the proposal is at:
https://github.com/jmgnc/cti-sep-repository/blob/digitalsig/seps/draft/extensions/x-newcontext-signing-ext/x-newcontext-signing-ext.md

It does not support third party signatures yet, but this is relatively
easy to write up if needed... After thinking about how versioning works,
and interactions w/ TAXII and other items, third party signatures need
to be their own SDO, otherwise it introduces complexities into the TAXII
server in how to aggregate signatures, where as having an independant
object makes it possible.. Though I realized that not being able to
add the reference hashes makes this idea more difficult, but not impossible..

Feel free to ask questions if you need more info...

--
John-Mark