Re: [cti-stix] Digital Signatures

[Andrew Storms <storms@newcontext.com>]

Hi Bret.

Thanks for sending this out. Its a topic that has been near and dear for our team at New Context for some time. John-Mark created a research/report/proposal draft a while back and shared it among our customers and a few other organizations in and out of the TC. As I recall, JMG also wrote some code to show how the design could be implemented.

Since the introduction of the SEP github repo, we've been working thru our backlog of CTI related work and submitting them so they can be viewed publicly. Take a look at:Âhttps://github.com/jmgnc/cti-sep-repository/blob/digitalsig/seps/draft/extensions/x-newcontext-signing-ext/x-newcontext-signing-ext.md

Please take a look at what we've done on this so far and make sure to pull in JMG.

Thanks

--S

On Fri, Oct 12, 2018 at 2:01 PM Bret Jordan <Bret_Jordan@symantec.com> wrote:

I have been doing some research and work on figuring out how to make digital signatures a reality for STIX. On the surface this seems like it should be really easy. But it is not until you peelÂback the layers that you begin to see that there is a set of problems (which I guess have been well known for years). I have reached out to the working group at the IETF that is responsible for JSON signatures and JSON encryption. You can follow that discussion on the jose@ietf.org mailing list.Â

Problems:

(1)ÂThere is no defined canonical serialization for JSON. This means the following examples are all possible depending on the JSON library and programming language you use.

{ "type"Â: "indicator", "id"Â: "indicator--1234"}

{"type":"indicator","id":"indicator--1234"}

{"id":"indicator--1234","type":"indicator"}

{

"id":"indicator--1234",

"type":"indicator"

}

{

  "id":"indicator--1234",

  "type":"indicator"

}

etc etc etc.

This means there is no way for a consumer to unmarshal the data and then verify the signature. The only thing they can do is verify the byte stream on receipt,Âwhich is what JOSE RFC 7515 defines. But if that organization (ISAC, ISAO, Vendor) decides to re-share the content back out, there is no guarantee that the STIX they send will match the attached signature (unless they keep a copy ofÂthe original byte stream and send it instead).

We can solve some of this by defining a canonical representation for STIX. Meaning, all white space is removed, all CR / CRLF are removed, all keys are sorted in some UTF8 friendly way. There are several personal drafts and solutions that have tried to address this [1], [2], [3].Â

(2) The JSON number type that we use in some parts of STIX is not uniformly deserialized. Meaning, some architectures / programming languages will deserialize it to a float, some to a double float, some to who-knows-what. This means that even if you define a canonical representation the signatures may still fail since one library may treat the number data differently.Â

We could solve this by making all STIX number types quoted strings. This is apparently the best practice in all IETF standards that use and define JSON. This has been a known problem for many years. So I would suggest that we consider changing our spec to say that all numbers, integers, floats, etc in STIX MUST be treated as strings, aka quoted strings in JSON.

Another option is to force all numbers to beÂcoerced into an IEEE 754 double precision number and be serialized according to ECMAScript V6+ rules. However, there is no library support for this.

3) There are a few other problems as well. One is thatÂ"\u0020" and " " both represents a space character. But once again I think these can all be addressed.ÂÂ

Ultimately I think this is a solvableÂproblem, but I do not feel that it should be solved completely in our TC. I think we should make our spec work better with JSON by changing our numbers to strings. ThenÂthose that are interested in ensuring that STIX content can be signed and maybe even encrypted, should help me work with the JOSE Working Group at theÂIETF to figure out a standard for canonical JSON and see about getting RFC 7515 updated to support this.

References:

1. https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
2. https://gibson042.github.io/canonicaljson-spec/
3. https://cyberphone.github.io/doc/security/jcs.html#Reference.JEF
   

Bret

--

Andrew Storms VP of Security Services PÂÂ707-477-4335 ÂÂ