Re: [cti-stix] Digital Signatures

[John-Mark Gurney <jmg@newcontext.com>]

Bret Jordan wrote this message on Fri, Oct 12, 2018 at 21:01 +0000:
> 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.

I have continued my efforts in this, and working on a SEP proposal at:
https://github.com/jmgnc/cti-sep-repository/blob/digitalsig/seps/draft/extensions/x-newcontext-signing-ext/x-newcontext-signing-ext.md

This is similar to the original proposal that I put forth, but using JCS
as the canonicalization format..

> 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].

Having read through 2, I don't feel that it's specific enough, and
also the implementations are lacking...

> (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.

This is, IMO, not workable, because now we have to define a canonical
way or parsing numbers and representing them...  Because if you store
the number in number form, and NOT string form, you are not able to
ensure that you serialize it back to the original format..

> 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.

All canonicalization libaries will do this for you..  And they should
raise an exception if they are unable to output the data w/o changing
it, e.g. trying to serialize 2**54+1 is not possible, and so should
raise an error or exception so bad data is not produceed...

> 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.

This will be a HUGE compatibility issue, both w/ existing content, and
generating content for existing software...  Also the software will now
have to have their own custom parser for numbers and serializer for
numbers.  No programmer will be able to simply pick up a language, use
the included JSON library and start generating content.  They will now
have to find a STIX library for their language...  This, IMO, defeates
the whole point of picking JSON as a serialization format for STIX...

-- 
John-Mark