Re: [cti-stix] Digital Signatures

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

Jason Keirstead wrote this message on Sat, Oct 13, 2018 at 18:19 -0300:
> However in general IMHO any STIX signature should not have anything to do 
> with JSON. We want to be signing content, not a specific serialization 
> thereof. If the way STIX defines signing requires JSON serialization, then 
> we can never have any other representation of STIX used or transmitted.

This is not correct.  As the data model, if data is serialized in
another format, say ASN.1, it should be able to be translated
into JSON format with the exact same values.  If it isn't able to, then
there is a problem with how we have defined the encoding systems.

> I think it might make a lot more sense to define a way to generate a 
> signature having nothing to do with JSON.

I'm fine w/ this.  I proposed this as an option, but at the F2F, most
everyone agreed that this wasn't a viable option..

I'm fine w/ picking something else, like ASN.1 DER as it is well
understood from a canonicalization and serialization perspective,
and there are already many libraries around supporting it.

> From:   Bret Jordan <Bret_Jordan@symantec.com>
> To:     "cti-stix@lists.oasis-open.org" <cti-stix@lists.oasis-open.org>
> Date:   10/12/2018 06:01 PM
> Subject:        [cti-stix] Digital Signatures
> Sent by:        <cti-stix@lists.oasis-open.org>
> 
> 
> 
> 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:
> https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
> https://gibson042.github.io/canonicaljson-spec/
> https://cyberphone.github.io/doc/security/jcs.html#Reference.JEF
> 
> Bret
> 
> 
> 

-- 
John-Mark